Page 1 of 5 123 ... LastLast
Results 1 to 10 of 48

Thread: CPU Scaling intel_pstate testing (3.10 kernel)

  1. #1
    Join Date
    Jun 2009
    Location
    0:0:0:0:0:0:0:1
    Beans
    4,109
    Distro
    Xubuntu 13.04 Raring Ringtail

    CPU Scaling intel_pstate testing (3.10 kernel)

    This is not for AMD CPUs just so you know

    Info:
    http://www.phoronix.com/scan.php?pag...tem&px=MTM3NDQ

    XFCE users may be interested in this script for the genmon applet, the icons are here (icons are from the gnome2 sensors/cpu freq applets)

    Do determine if your CPU uses the new intel_pstate driver, you will need the 3.10 kernel, then run this
    Code:
    cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
    You will get 1 line for every core/thread your CPU has, it is gives you intel_pstate you can try it out
    I have been watching my core frequencies on my laptop, so far I have found 67 speeds it will use, which is way more than it used under the old method of cpu scaling

    I have written a PHP script to find frequencies (requires that php5-cli be installed)
    On line 3 you can fill out known speeds like this
    On line 6 you can change the number 60 to make it search for more or less time, the script uses a brute force method to find frequencies so more time will have more results
    You will need to add read access to this, by default only root can read it
    sudo chmod 444 /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq

    I also made another script to track the cpu frequency

    On my laptop my 67 known speeds are
    Code:
     782 Mhz as  34%
     805 Mhz as  35%
     828 Mhz as  36%
     851 Mhz as  37%
     874 Mhz as  38%
     897 Mhz as  39%
     920 Mhz as  40%
     943 Mhz as  41%
     966 Mhz as  42%
     989 Mhz as  43%
    1012 Mhz as  44%
    1035 Mhz as  45%
    1058 Mhz as  46%
    1081 Mhz as  47%
    1104 Mhz as  48%
    1127 Mhz as  49%
    1150 Mhz as  50%
    1173 Mhz as  51%
    1196 Mhz as  52%
    1219 Mhz as  53%
    1242 Mhz as  54%
    1265 Mhz as  55%
    1288 Mhz as  56%
    1311 Mhz as  57%
    1334 Mhz as  58%
    1357 Mhz as  59%
    1380 Mhz as  60%
    1403 Mhz as  61%
    1426 Mhz as  62%
    1449 Mhz as  63%
    1472 Mhz as  64%
    1495 Mhz as  65%
    1518 Mhz as  66%
    1541 Mhz as  67%
    1564 Mhz as  68%
    1587 Mhz as  69%
    1610 Mhz as  70%
    1633 Mhz as  71%
    1656 Mhz as  72%
    1679 Mhz as  73%
    1702 Mhz as  74%
    1725 Mhz as  75%
    1748 Mhz as  76%
    1771 Mhz as  77%
    1794 Mhz as  78%
    1817 Mhz as  79%
    1840 Mhz as  80%
    1863 Mhz as  81%
    1886 Mhz as  82%
    1909 Mhz as  83%
    1932 Mhz as  84%
    1955 Mhz as  85%
    1978 Mhz as  86%
    2001 Mhz as  87%
    2024 Mhz as  88%
    2047 Mhz as  89%
    2070 Mhz as  90%
    2093 Mhz as  91%
    2116 Mhz as  92%
    2139 Mhz as  93%
    2162 Mhz as  94%
    2185 Mhz as  95%
    2208 Mhz as  96%
    2231 Mhz as  97%
    2254 Mhz as  98%
    2277 Mhz as  99%
    2300 Mhz as 100%
    the strange thing is my 1st speed, if I run cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_min_freq I should get the lowest possible frequency the system will use which is 800 MHz, however the system has been seen running at 782 MHz
    I actually just noticed the CPU seems to run at every percentage point, thanks to the sorted data. The script does round the percentages, but I turned rounding off and they are all exact values
    I am unable to test turbo core stuff as I don't have any hardware that can do that, i would like to know if the cpuinfo_cur_freq files shows turbo
    Last edited by pqwoerituytrueiwoq; June 6th, 2013 at 09:30 PM. Reason: typo/touch up
    Laptop: ASUS A54C-NB91 (Storage: WD3200BEKT + MKNSSDCR60GB-DX); Desktop: Custom Build - Images included; rPi Server
    Putting your Networked Printer's scanner software to shame PHP Scanner Server
    I frequently edit my post when I have the last post

  2. #2
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    1,414
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: CPU Scaling intel_pstate testing (3.10 kernel)

    Quote Originally Posted by pqwoerituytrueiwoq View Post
    I am unable to test turbo core stuff as I don't have any hardware that can do that, i would like to know if the cpuinfo_cur_freq files shows turbo
    It does show the actual turbo frequencies and is now never different that the results of
    Code:
    grep MHz /proc/cpuinfo
    at least that I have seen so far. In this example my system is 3.4 GHz with turbo up to 3.8 GHz, and I have CPU 7 fully loaded:
    Code:
    doug@s15:~/temp$ grep MHz /proc/cpuinfo
    cpu MHz         : 3672.000
    cpu MHz         : 3672.000
    cpu MHz         : 3672.000
    cpu MHz         : 3774.000
    cpu MHz         : 3672.000
    cpu MHz         : 3672.000
    cpu MHz         : 3672.000
    cpu MHz         : 3774.000
    doug@s15:~/temp$ sudo cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
    3672000
    3638000
    3672000
    3774000
    3672000
    3672000
    3604000
    3774000
    (slight differences because of time delay between commands. It is CPU 7 that matters for this example.)

    With turbo turned off, I get many CPU frequencies, but not one for every percent setting, with turbo turned on, I seem to get less frequencies. Also, I am finding some weird things with this new frequency scaling stuff, and it isn't backwards compatible with how things were. I need some time (a day or two) to make a better and more compete posting here, as there are tests I didn't get to yet.

    Other readers: pq...q and I were on another thread and went off on a tangent about this. It was decided to start a new thread here.
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

  3. #3
    Join Date
    Jun 2009
    Location
    0:0:0:0:0:0:0:1
    Beans
    4,109
    Distro
    Xubuntu 13.04 Raring Ringtail

    Re: CPU Scaling intel_pstate testing (3.10 kernel)

    did you try my php script to find frequencies, i set the loop to 500 (line 6) and went and did stuff, that should find most of your speeds
    nice to know that my genmon plugin supports turbo core on this new driver
    i am supried you can have turbo running on 8 threads at the same time, i thought it had to downclock 1 or more cores to up the clock on another core, could be a bug in the driver
    Laptop: ASUS A54C-NB91 (Storage: WD3200BEKT + MKNSSDCR60GB-DX); Desktop: Custom Build - Images included; rPi Server
    Putting your Networked Printer's scanner software to shame PHP Scanner Server
    I frequently edit my post when I have the last post

  4. #4
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    1,414
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: CPU Scaling intel_pstate testing (3.10 kernel)

    Quote Originally Posted by pqwoerituytrueiwoq View Post
    did you try my php script to find frequencies, i set the loop to 500 (line 6) and went and did stuff, that should find most of your speeds
    No I didn't. I already had a way of doing it, so continued with my method. I'll have a look at your method later on.
    I am supried you can have turbo running on 8 threads at the same time, i thought it had to downclock 1 or more cores to up the clock on another core, could be a bug in the driver
    I only had one CPU fully loaded, and I actually never see my non-idle CPU's at different actual frequencies. If I fully load all 8 of my CPU's, the frequency does drop a little:
    Code:
    New P-state driver - all CPU's loaded (governor = PERFORMANCE)
    doug@s15:~/temp$ grep MHz /proc/cpuinfo
    cpu MHz         : 3468.000
    cpu MHz         : 3468.000
    cpu MHz         : 3468.000
    cpu MHz         : 3468.000
    cpu MHz         : 3468.000
    cpu MHz         : 3468.000
    cpu MHz         : 3468.000
    cpu MHz         : 3468.000
    
    Old p_state driver - all CPU's loaded (turbostat is the only way to know the actual frequency)
    doug@s15:~/temp$ sudo ./turbostat
     cr CPU    %c0  GHz  TSC    %c1    %c3    %c6    %c7  %pc2  %pc3  %pc6  %pc7
             100.00 3.51 3.41   0.00   0.00   0.00   0.00  0.00  0.00  0.00  0.00
       0   0 100.00 3.51 3.41   0.00   0.00   0.00   0.00  0.00  0.00  0.00  0.00
       0   4 100.00 3.51 3.41   0.00   0.00   0.00   0.00  0.00  0.00  0.00  0.00
       1   1 100.00 3.51 3.41   0.00   0.00   0.00   0.00  0.00  0.00  0.00  0.00
       1   5 100.00 3.51 3.41   0.00   0.00   0.00   0.00  0.00  0.00  0.00  0.00
       2   2 100.00 3.51 3.41   0.00   0.00   0.00   0.00  0.00  0.00  0.00  0.00
       2   6 100.00 3.51 3.41   0.00   0.00   0.00   0.00  0.00  0.00  0.00  0.00
       3   3 100.00 3.51 3.41   0.00   0.00   0.00   0.00  0.00  0.00  0.00  0.00
       3   7 100.00 3.51 3.41   0.00   0.00   0.00   0.00  0.00  0.00  0.00  0.00
    Edit: The New P-state driver all CPUs loaded example above was for PERFORMACE governor. Below is for POWERSAVE governor.
    Code:
    doug@s15:~/temp$ grep MHz /proc/cpuinfo
    cpu MHz         : 1768.000
    cpu MHz         : 1768.000
    cpu MHz         : 1768.000
    cpu MHz         : 1768.000
    cpu MHz         : 1768.000
    cpu MHz         : 1768.000
    cpu MHz         : 1768.000
    cpu MHz         : 1768.000
    Edit 2: But that is inconsistent, as I did it again adding 1 CPU 100% load at a time, and ended up at a different clock frequency for all 8 CPUs loaded:
    1 CPU 100% loaded, Frequency: 3.774 GHz
    2 CPUs 100% loaded, Frequency: 3.570 GHz
    3 CPUs 100% loaded, Frequency: 3.570 GHz
    4 CPUs 100% loaded, Frequency: 3.468 GHz
    5 CPUs 100% loaded, Frequency: 3.468 GHz
    6 CPUs 100% loaded, Frequency: 3.468 GHz
    7 CPUs 100% loaded, Frequency: 3.468 GHz
    8 CPUs 100% loaded, Frequency: 3.468 GHz

    Edit: Adding what "turbostat -v" says for max Vs. cores used:
    Code:
    doug@s15:~/temp$ sudo ./turbostat -v
    GenuineIntel 13 CPUID levels; family:model:stepping 0x6:2a:7 (6:42:7)
    16 * 100 = 1600 MHz max efficiency
    34 * 100 = 3400 MHz TSC frequency
    35 * 100 = 3500 MHz max turbo 4 active cores
    36 * 100 = 3600 MHz max turbo 3 active cores
    37 * 100 = 3700 MHz max turbo 2 active cores
    38 * 100 = 3800 MHz max turbo 1 active cores
    Last edited by Doug S; June 6th, 2013 at 03:30 PM. Reason: Added turbostat -v output
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

  5. #5
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    1,414
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: CPU Scaling intel_pstate testing (3.10 kernel)

    The current, or "old" frequency scaling driver for intel stuff has issues and sometimes gives false information, so when pq...q mentioned there was a new p-state driver in the 3.10 series kernel I wanted to have a test drive.

    Summary: There are issues.

    My system: i7 @ 3.4 GHz with turbo to 3.8 GHz and a minimum frequency of 1.6 GHz (42% of 3.8 GHz. The new driver uses percents.)

    Experiment: Set powersave mode on all CPUs: Other stuff = default

    What used to happen: All CPU's would always be at 1.6 GHz.

    What happens now:

    Load CPU 7: (taskset -c 7 ./testtme): (testtme is a simple CPU loading program that actually does nothing.)
    Sometimes it will go immediately to 3.774 GHz
    Sometimes it will go to 3.774 GHz after a few seconds
    Sometimes it will go to 1.768 Ghz and stay there (tested to 426 seconds duration).

    Similar results for other CPUs.

    Now: turn off turbo
    Sometimes it will go immediately to 3.40 GHz
    Sometimes it will go to 3.40 GHz after a few seconds
    Sometimes it will go to 1.768 Ghz and stay there (tested to 260 seconds duration) (rate is about 1 in 10 to 1 in 20 times)

    Experiment: Set performance mode on all CPUs: Other stuff = default

    Loaded CPU will go immediately to 3.774 GHz

    Now: turn off turbo
    Sometimes loaded CPU will go to 1.768 GHz and stay there. (tested for 25 seconds duration).
    Mostly it will go to 3.4 GHz.

    Experiment: How many frequencies are used?
    Method: set the min and max percent frequencies to the same value.
    See attached graphs, for both reported frequencies and as calculated (sanity check).

    Why the large jump in frequencies? Do they not work for some reason?
    Boot back to an older kernel (old driver), the list of available frequencies is:
    Code:
    doug@s15:~/temp$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
    3401000 3400000 3300000 3100000 3000000 2900000 2800000 2600000 2500000 2400000 2200000 2100000 2000000 1900000 1700000 1600000
    And so I tried each of the available frequencies that were bypassed by the new driver, namely 1.9, 2.0, 2.1, 2.2, 2.4, and 2.5 GHz. I used the userspace governor. All the frequencies worked fine: Example:
    Code:
    doug@s15:~/temp$ cat set_cpu_userspace
    #! /bin/bash
    cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    
    for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo "userspace" > $file; done
    
    for file in /sys/devices/system/cpu/cpu*/cpufreq/scaling_setspeed; do echo "2500000" > $file; done
    
    cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
    
    grep MHz /proc/cpuinfo
    Code:
    doug@s15:~/temp$ sudo ./turbostat
     cr CPU    %c0  GHz  TSC    %c1    %c3    %c6    %c7  %pc2  %pc3  %pc6  %pc7
              12.52 2.51 3.41  19.83   0.00  67.66   0.00  0.00  0.00  0.00  0.00
       0   0   0.02 2.51 3.41   0.65   0.00  99.33   0.00  0.00  0.00  0.00  0.00
       0   4   0.05 2.51 3.41   0.62   0.00  99.33   0.00  0.00  0.00  0.00  0.00
       1   1   0.02 2.51 3.41  15.46   0.00  84.52   0.00  0.00  0.00  0.00  0.00
       1   5   0.00 2.51 3.41  15.48   0.00  84.52   0.00  0.00  0.00  0.00  0.00
       2   2   0.01 2.51 3.41  13.20   0.00  86.79   0.00  0.00  0.00  0.00  0.00
       2   6   0.00 2.50 3.41  13.21   0.00  86.79   0.00  0.00  0.00  0.00  0.00
       3   3   0.01 2.51 3.41  99.99   0.00   0.00   0.00  0.00  0.00  0.00  0.00
       3   7 100.00 2.51 3.41   0.00   0.00   0.00   0.00  0.00  0.00  0.00  0.00
    Edit: The original graphs (one now replaced) were done with increasing percent requested frequencies. New tests were done with decreasing percent requested frequencies, and then the big gap in frequencies was not present.
    Attached Images Attached Images
    Last edited by Doug S; June 7th, 2013 at 05:14 PM. Reason: changed an attached graph
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

  6. #6
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    1,414
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: CPU Scaling intel_pstate testing (3.10 kernel)

    Results on my computer (governor = POWERSAVE; tubo on) using pq...q's php script:
    Code:
    Total found: 50
    Sorted data:
    1598 Mhz as  42%
    1632 Mhz as  43%
    1666 Mhz as  44%
    1700 Mhz as  45%
    1734 Mhz as  46%
    1768 Mhz as  47%
    1802 Mhz as  47%
    1836 Mhz as  48%
    1870 Mhz as  49%
    1904 Mhz as  50%
    1938 Mhz as  51%
    1972 Mhz as  52%
    2006 Mhz as  53%
    2040 Mhz as  54%
    2074 Mhz as  55%
    2108 Mhz as  55%
    2142 Mhz as  56%
    2176 Mhz as  57%
    2210 Mhz as  58%
    2244 Mhz as  59%
    2278 Mhz as  60%
    2312 Mhz as  61%
    2346 Mhz as  62%
    2380 Mhz as  63%
    2414 Mhz as  64%
    2448 Mhz as  64%
    2516 Mhz as  66%
    2550 Mhz as  67%
    2618 Mhz as  69%
    2686 Mhz as  71%
    2856 Mhz as  75%
    2924 Mhz as  77%
    2992 Mhz as  79%
    3060 Mhz as  81%
    3094 Mhz as  81%
    3162 Mhz as  83%
    3196 Mhz as  84%
    3230 Mhz as  85%
    3366 Mhz as  89%
    3400 Mhz as  89%
    3468 Mhz as  91%
    3502 Mhz as  92%
    3536 Mhz as  93%
    3570 Mhz as  94%
    3604 Mhz as  95%
    3638 Mhz as  96%
    3672 Mhz as  97%
    3706 Mhz as  98%
    3740 Mhz as  98%
    3774 Mhz as  99%
    Why so different than what I found? It includes all CPU states, including idle and such in between. I was only using active CPU (in the c0 state, I think it is called) information and was trying to specifically set CPU frequencies. There is work that I do, where I must know that I can "lock" the CPU frequency at some value.
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

  7. #7
    Join Date
    Jun 2009
    Location
    0:0:0:0:0:0:0:1
    Beans
    4,109
    Distro
    Xubuntu 13.04 Raring Ringtail

    Re: CPU Scaling intel_pstate testing (3.10 kernel)

    I am sure there are more than just those
    can you post the output of this
    cat /sys/devices/system/cpu/cpu*/cpufreq/{scaling_max_freq,cpuinfo_max_freq}
    you don't have the max freq i would expect (3.4GHz)
    your turbo core speed seems to be the norm maxi expected to see something like
    3774 MHz as 130%
    Laptop: ASUS A54C-NB91 (Storage: WD3200BEKT + MKNSSDCR60GB-DX); Desktop: Custom Build - Images included; rPi Server
    Putting your Networked Printer's scanner software to shame PHP Scanner Server
    I frequently edit my post when I have the last post

  8. #8
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    1,414
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: CPU Scaling intel_pstate testing (3.10 kernel)

    Code:
    doug@s15:~/temp$ cat /sys/devices/system/cpu/cpu*/cpufreq/{scaling_max_freq,cpuinfo_max_freq}
    3800000
    3800000
    3800000
    3800000
    3800000
    3800000
    3800000
    3800000
    3800000
    3800000
    3800000
    3800000
    3800000
    3800000
    3800000
    3800000
    With turbo enabled 100% = 3.8 GHz. With turbo disabled 100% = 3.4 GHz (see also my graphs in previous post)
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

  9. #9
    Join Date
    Jun 2009
    Location
    0:0:0:0:0:0:0:1
    Beans
    4,109
    Distro
    Xubuntu 13.04 Raring Ringtail

    Re: CPU Scaling intel_pstate testing (3.10 kernel)

    I did some more testing, the CPU cores seem to run at the same speed as the other cores, can you confirm this (i only have 2 cores)
    there is a new script in post 1 and in the thread you linked in your 1st post

    a couple times they are not the same in the chart, but the script runs leaner so it can't get both core's current speed at the same nanosecond second, it is way too close to be coincidence

    If your system does the same with turbo on file a bug report, there is no way that is the correct behavior for it,if they are the same with turbo when over 3.4Ghz that is overclocking not turbo
    Attached Files Attached Files
    Last edited by pqwoerituytrueiwoq; June 6th, 2013 at 09:00 PM.
    Laptop: ASUS A54C-NB91 (Storage: WD3200BEKT + MKNSSDCR60GB-DX); Desktop: Custom Build - Images included; rPi Server
    Putting your Networked Printer's scanner software to shame PHP Scanner Server
    I frequently edit my post when I have the last post

  10. #10
    Join Date
    Feb 2011
    Location
    Coquitlam, B.C. Canada
    Beans
    1,414
    Distro
    Ubuntu 12.04 Precise Pangolin

    Re: CPU Scaling intel_pstate testing (3.10 kernel)

    Quote Originally Posted by pqwoerituytrueiwoq View Post
    I did some more testing, the CPU cores seem to run at the same speed as the other cores, can you confirm this (i only have 2 cores)
    Yes, for any CPU in the C0 state, the frequency is always the same. This was an issue with the previous frequency scaling driver, as it gave the impression that different CPU's were at different speeds when in fact they were not. When a CPU is not in the C0 state, then, myself, I don't care what is listed for frequency.
    If your system does the same with turbo on file a bug report, there is no way that is the correct behavior for it,if they are the same with turbo when over 3.4Ghz that is overclocking not turbo
    I disagree. Both the old scaling driver and the new one are, if not the same, at least similar in this regard, and as far I a have seen obey the re-rating rules as per the output from "turbostat -v" that I added a few hours ago to the end of my post #4 above.

    Now, for my post #5 above, I wrote things like "sometimes I get this" and "sometimes get that". I wanted to get a better value for the actual probability that the CPU will not step up to the frequency it should get to.

    With turbo off and POWERSAVE governor, 1020 times I launched a 100% CPU loading task on CPU 7 and then asked for the CPU frequency after 5 seconds; 222 times it was 1.768 GHz; once it was 2.788 GHz; 307 times it was 3.366 GHz; and 490 times it was 3.4 GHz. I think, with no proof, 3.366 and 3.4 are the same within some noise or whatever. So the probability that it doesn't step up properly is about 22%. I'll do some other scenarios, but this test take 5 hours. This, I think, is a bug. Does anyone else see this issue? It might be more probable for me, as I run ubuntu server and not desktop, so all of my CPU's are more likely to be idle at the start of the each sample loop than ubuntu desktop CPUs.

    I did the same as the above test, but 1000 times and not specifying a CPU. The CPU frequency did not ramp up many times. Exact numbers are not known, because I did not know which CPU frequency to measure.

    Turbo = on; governor = POWERSAVE; Samples 672; In 19.9% of samples, the CPU did not step up.
    Data: Samples 672; 134 samples were 1.768 GHz; 1 sample was 2.176 GHz; 277 samples were 3.672 GHz (meaning another core was doing something); 2 samples were 3.740 GHz; 253 samples were 3.774 GHz.

    Turbo on; governor = PERFORMANCE; Samples 1000; In 0 % of samples, the CPU did not step up.
    Data: Samples 1000; 13 samples were 3.57 GHz (meaning two other cores were doing something); 524 samples were 3.672 GHz (meaning another core was doing something); 5 samples were 3.74 GHz; 458 samples were 3.774 GHz.
    Last edited by Doug S; June 7th, 2013 at 03:11 PM. Reason: adding test results as they come
    Any follow-up information on your issue would be appreciated. Please have the courtesy to report back.

Page 1 of 5 123 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •