Hypfer / i7z

Automatically exported from code.google.com/p/i7z
GNU General Public License v2.0
1 stars 0 forks source link

sandy bridge multiplier in turbo mode #25

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. OC Sandy Bridge system
2. run i7z
3. check Actual Freq (Mult.)

What is the expected output? What do you see instead? If possible do paste
the output

I expect the output to show the TRUE frequency with the TRUE multiplier which 
should be way higher in an overclocked environment.

In cpuz under Win7 I get beween 4.000 and 4.500 MHZ as Core Speed and a 
multiplier between 42x and 45x.

See my i7z output under heavy load (multithreaded x264 encoding) in attached 
i7z.txt

What version of the product are you using (the download version or the svn
version and which one)? On what operating system?
BTW is it a 32-bit or a 64-bit OS/Kernel?

i7z-svn 51-1

Linux 2.6.37-ARCH #1 SMP PREEMPT x86_64 Intel(R) Core(TM) i7-2600K CPU @ 
3.40GHz GenuineIntel GNU/Linux

Please provide any additional information below (helpful will be platform
information like number and types of cpus, motherboard and a copy of
/proc/cpuinfo)

Intel® Core™ i7-2600K Processor

Asus P8P67 EVO Motherboard

Also, please see attached cpuinfo.txt

Original issue reported on code.google.com by getag...@web.de on 5 Mar 2011 at 4:29

Attachments:

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. OC Sandy Bridge system 

=> With OC I mean overclocked.

Original comment by getag...@web.de on 5 Mar 2011 at 4:30

GoogleCodeExporter commented 8 years ago
thanks a lot for the bug report. its high on my todo list.

i am guessing intel has changed how it puts the max turbo value in the 
register. i will take a look at the latest doc and update.

Original comment by abhirana on 6 Mar 2011 at 10:08

GoogleCodeExporter commented 8 years ago
Not working for Version 0.27 (2/Aug/11) and the SVN version.
I still get the wrong output.

Original comment by getag...@web.de on 3 Aug 2011 at 5:04

GoogleCodeExporter commented 8 years ago
hi

will it be possible to see if turbostat 
(http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/turbostat
/turbostat.c , you will need to compile using gcc -o turbostat turbostat.c and 
then ./turbostat)gives the same results or different? we could find out if its 
a problem with the tool or something else

also what multipliers and bclk freq are reported in windows?

the one other thing i can think of is disabling cpufreq via modprobe -r cpufreq 
maybe thats limiting your top frequency.

regards

Original comment by abhirana on 3 Aug 2011 at 5:20

GoogleCodeExporter commented 8 years ago
I had the same problem (and also the same CPU). The real reason was that my 
installation of Linux didn't trigger the turbo, even when the same installation 
worked on the first generation of i7's.

I got it working by loading acpi_cpufreq module. Now I can see that i7z (SVN 
r56) displays turbo correctly for Sandy Bridge CPUs.

Original comment by 00j...@gmail.com on 5 Aug 2011 at 4:51

GoogleCodeExporter commented 8 years ago
Gee, loading acpi_cpufreq module did the trick, thanks!

Original comment by getag...@web.de on 19 Aug 2011 at 7:47

GoogleCodeExporter commented 8 years ago
I have an i5 2500K and the i7z program reads the turbo multiplier correctly. 
Unfortunately, when I run handbrake, the speeds and multipliers increase then
they read as "Garbage." Why would this program affect the output in this way?

J

Original comment by piconew...@gmail.com on 4 Sep 2011 at 1:05

GoogleCodeExporter commented 8 years ago
@piconew...

the issue i had once was that the sum total of residency in various C states is 
equal to 100 but not always so due to the fact that i dont read it all values 
at once and it may happen that due to some jitter that sum increased or 
decreased from what is expected.
What i did then was change the code so that if the sum total is >100% it will 
say garbage results. but this doesnot always work in all cases like 
overclocking or under duress (like due to load the time counters are read a bit 
later, etc. i personally seen it sometimes happen when the cores are initially 
loaded and the scheduler pushes i7z down in priority.

i check this range via a macro in i7z.h at line 163 
http://code.google.com/p/i7z/source/browse/trunk/i7z.h#163

i.e. i check whether the range is between 0-105%  and only print it then. right 
now i have set it to 105, change it to a larger number.

#define IS_THIS_BETWEEN_0_100(cond) (cond>=-1 && cond <=105 && !isinf(cond) && 
!isnan(cond))? 1: 0

change the upper limit to 125
#define IS_THIS_BETWEEN_0_100(cond) (cond>=-1 && cond <=125 && !isinf(cond) && 
!isnan(cond))? 1: 0

and this should hopefully fix the garbage values 

Original comment by abhirana on 6 Sep 2011 at 2:31