If it ain't broke... fix it until it is.
Well.. Core Temp will always use the lowest available multiplier to calculate speed if the real frequency it calculated is lower.
This is the algorithm I use:
- Get thread frequency
- Calculate closest half-multiplier by dividing frequency by FSB/Bus speed
- Multiplier = Max(Calculated_Multiplier, Minimum_CPU_Multiplier)
So if the calculated multiplier is lower than the minimum CPU multiplier, it uses the minimum multiplier.
Member of Overclockers.com Folding @ Home team
"<The_Coolest> you can't unwaste wasted CPU cycles" - Start FOLDing now!
Main rig:
AMD Ryzen 7 2700X / Mobo: Asrock Fatal1ty X470 / EVO 970 500GB + WD Blue 250GB + HDD / GPU: Dell RX 570 4GB / Mem: 2x16GB DDR4-3200 G.Skill 32GTZKW TridentZ - 32GB total / PSU: Seasonic Prime Ultra Gold 650W
Secondary rigs:
Core i7 2600K 3.4GHz @ 4.3GHz (Scythe Mugen2) / Mobo: Biostar TP67XE / 2x Inland Pro 120GB / GPU: HD5450 / Mem: 4x4GB DDR3-1600 G.Skill 8GBXL RipJawsX - 16GB total / PSU: Seasonic S12II 620W.
Core i3 540 3.06GHz @ 4.0GHz (Freezer 7 Pro) / Mobo: MSI H55M-ED55 / GPU: Integrated / Mem: 4x2GB DDR3-1600 G.Skill 4GBRL RipJaws - 8GB total / PSU: Antec 380W.
Core Temp - Accurate temperature monitor for Intel's Core/Core 2 and AMD64 processors
It buggy! 99.6
![]()
EVGA 780I
Q9650 @ 3.6GHZ 9x400
4x1Gig of OCZ Gamer X
ATI 5850
HP 42Inch 1080P LCD
SilverStone 1k Op
Member of Overclockers.com Folding @ Home team
"<The_Coolest> you can't unwaste wasted CPU cycles" - Start FOLDing now!
Main rig:
AMD Ryzen 7 2700X / Mobo: Asrock Fatal1ty X470 / EVO 970 500GB + WD Blue 250GB + HDD / GPU: Dell RX 570 4GB / Mem: 2x16GB DDR4-3200 G.Skill 32GTZKW TridentZ - 32GB total / PSU: Seasonic Prime Ultra Gold 650W
Secondary rigs:
Core i7 2600K 3.4GHz @ 4.3GHz (Scythe Mugen2) / Mobo: Biostar TP67XE / 2x Inland Pro 120GB / GPU: HD5450 / Mem: 4x4GB DDR3-1600 G.Skill 8GBXL RipJawsX - 16GB total / PSU: Seasonic S12II 620W.
Core i3 540 3.06GHz @ 4.0GHz (Freezer 7 Pro) / Mobo: MSI H55M-ED55 / GPU: Integrated / Mem: 4x2GB DDR3-1600 G.Skill 4GBRL RipJaws - 8GB total / PSU: Antec 380W.
Core Temp - Accurate temperature monitor for Intel's Core/Core 2 and AMD64 processors
I disagree with the new method you are using to determine the multiplier. Here's an example.
On a Core 2 mobile CPU when you disable SpeedStep / EIST, the multiplier will get locked at whatever value it is presently at. In the picture, EIST is disabled and the multiplier is locked at 11.5. It doesn't matter whether the CPU is at full load or idle or anywhere in between. The multiplier is locked and is not changing.
The value in Model Specific Register (MSR) 0x198 confirms that the multiplier is at 11.5. The timers you are using may indicate that the CPU is idle which it is but that doesn't mean the multiplier has dropped down to 6.0 because it hasn't. It can't. It's physically impossible when the EIST bit has been disabled.
The method RealTemp and ThrottleStop use is based on the Intel Turbo White Paper.
http://download.intel.com/design/pro...ots/320354.pdf
It recommends that you use the timers in MSR 0x30A and MSR 0x30B and compare those two timers to determine the multiplier. This method is for the Core i7 but it also works very well on most Core 2 CPUs. It doesn't work on the Atom CPUs because the one's that I've seen don't have these timers. This method also needs a slight modification to work correctly on the QX CPUs which ThrottleStop should handle correctly and the next version of RealTemp will get this fix too.
If you are using the MPERF and APERF timers then I don't think that is the best way to determine the actual multiplier. The results go against what is being reported by the method outlined in the Turbo White Paper.
If you need some more information about this method then just ask.
I tend to agree with you. I will just keep this as an option for Core 2 users in the upcoming release.
The way described in that document is not the best method for all of Nehalem family CPUs, if you want to properly show Turbo on all of the newer Nehalem based processors, like Lynfield, this will not always work. I personally don't have a Nehalem to experiment on, but I was told about this by an Intel guy who knows this stuff.
I use the following formula right now for frequency calculation:
(IA32_FIXED_CTR1(T1) - IA32_FIXED_CTR1(T0)) / (T1 - T0)
This works very well for all Nehalem based architecture, but for Core 2 it only gives you the active clock cycles (which you could call "effective" frequency), but not the physical frequency that the processor is operating at.
Member of Overclockers.com Folding @ Home team
"<The_Coolest> you can't unwaste wasted CPU cycles" - Start FOLDing now!
Main rig:
AMD Ryzen 7 2700X / Mobo: Asrock Fatal1ty X470 / EVO 970 500GB + WD Blue 250GB + HDD / GPU: Dell RX 570 4GB / Mem: 2x16GB DDR4-3200 G.Skill 32GTZKW TridentZ - 32GB total / PSU: Seasonic Prime Ultra Gold 650W
Secondary rigs:
Core i7 2600K 3.4GHz @ 4.3GHz (Scythe Mugen2) / Mobo: Biostar TP67XE / 2x Inland Pro 120GB / GPU: HD5450 / Mem: 4x4GB DDR3-1600 G.Skill 8GBXL RipJawsX - 16GB total / PSU: Seasonic S12II 620W.
Core i3 540 3.06GHz @ 4.0GHz (Freezer 7 Pro) / Mobo: MSI H55M-ED55 / GPU: Integrated / Mem: 4x2GB DDR3-1600 G.Skill 4GBRL RipJaws - 8GB total / PSU: Antec 380W.
Core Temp - Accurate temperature monitor for Intel's Core/Core 2 and AMD64 processors
The Intel Turbo White Paper method has worked correctly on every CPU I've seen that is based on the Core i architecture including the Lynnfield series.
If you ever find a user with a CPU and RealTemp doesn't accurately report the multiplier, can you ask him to contact me. I have found this method to be extremely reliable as long as other monitoring programs like HW Monitor or Everest are not randomly resetting the internal timers. I have been using this method for over a year and a half now without any major complaints. It's accurate at idle or full load or anywhere in between at reporting the correct multiplier.
I also don't own a Nehalem to test with but I'll ask a friend to give your method a try to see how it works on his Core i7.
This is with coretemp latest beta 99.6.2. My i950 is currently at 4370 (23x190). eist, c1e and turbo are all off, so frequency is always 4370.
pic 1....At idle coretemp is reporting 12x190 (incorrect), though realtemp, cpuz, and everest report the correct frequency 23x190, ie 4370.
pic 2....At intemittent linx load coretemp reports 50% time I am at 22x190 (incorrect). Realtemp, cpuz, everest report correct frequency all the time 23x190, except on occasion when cpuz weirds out and gives me world record frequencies.
pic 3...At 100% prime load, coretemp reports correct frequency about 80% time, 20% time again wrong frequency 22x190
Last edited by rge; 05-16-2010 at 05:54 PM.
Member of Overclockers.com Folding @ Home team
"<The_Coolest> you can't unwaste wasted CPU cycles" - Start FOLDing now!
Main rig:
AMD Ryzen 7 2700X / Mobo: Asrock Fatal1ty X470 / EVO 970 500GB + WD Blue 250GB + HDD / GPU: Dell RX 570 4GB / Mem: 2x16GB DDR4-3200 G.Skill 32GTZKW TridentZ - 32GB total / PSU: Seasonic Prime Ultra Gold 650W
Secondary rigs:
Core i7 2600K 3.4GHz @ 4.3GHz (Scythe Mugen2) / Mobo: Biostar TP67XE / 2x Inland Pro 120GB / GPU: HD5450 / Mem: 4x4GB DDR3-1600 G.Skill 8GBXL RipJawsX - 16GB total / PSU: Seasonic S12II 620W.
Core i3 540 3.06GHz @ 4.0GHz (Freezer 7 Pro) / Mobo: MSI H55M-ED55 / GPU: Integrated / Mem: 4x2GB DDR3-1600 G.Skill 4GBRL RipJaws - 8GB total / PSU: Antec 380W.
Core Temp - Accurate temperature monitor for Intel's Core/Core 2 and AMD64 processors
I downloaded the latest beta too and I have same problem. Hardware in sig.
Same problem as who/what?
Member of Overclockers.com Folding @ Home team
"<The_Coolest> you can't unwaste wasted CPU cycles" - Start FOLDing now!
Main rig:
AMD Ryzen 7 2700X / Mobo: Asrock Fatal1ty X470 / EVO 970 500GB + WD Blue 250GB + HDD / GPU: Dell RX 570 4GB / Mem: 2x16GB DDR4-3200 G.Skill 32GTZKW TridentZ - 32GB total / PSU: Seasonic Prime Ultra Gold 650W
Secondary rigs:
Core i7 2600K 3.4GHz @ 4.3GHz (Scythe Mugen2) / Mobo: Biostar TP67XE / 2x Inland Pro 120GB / GPU: HD5450 / Mem: 4x4GB DDR3-1600 G.Skill 8GBXL RipJawsX - 16GB total / PSU: Seasonic S12II 620W.
Core i3 540 3.06GHz @ 4.0GHz (Freezer 7 Pro) / Mobo: MSI H55M-ED55 / GPU: Integrated / Mem: 4x2GB DDR3-1600 G.Skill 4GBRL RipJaws - 8GB total / PSU: Antec 380W.
Core Temp - Accurate temperature monitor for Intel's Core/Core 2 and AMD64 processors
The only CPUs I've found that the whitepaper method doesn't work on is the Atom line because the timers in MSR 0x30A and 0x30B are not functional. There might be some Core 2 ES CPUs with the same problem but I haven't heard of any. Correction: I forgot. There was one user a long time ago with a QX6700 ES that didn't have these timers.
This method works great on all of the Core 2 CPUs that I've tested. The QX is a bit of an odd ball because the base multiplier can change depending on what multiplier you set in the bios. As you know, on all of the newer Core i CPUs, the base multiplier is fixed and it is easy to read the base multiplier from a register.
With the QX you need to check MSR 0x17 for the base multiplier. If the multiplier in the EDX register of MSR 0x198 is less than the multiplier in MSR 0x17, you have to use the lower value in MSR 0x198 as the base multiplier.
For the rest of the Core 2 CPUs, the base multiplier is in EAX of MSR 0x17. Once you have this, you multiply by the ratio that the two timers are running at and you have an accurate value for the multiplier. The advantage of this method is that it can correctly detect Intel Dynamic Acceleration which Intel uses on a lot of their mobile Core 2 CPUs. It also detects SLFM very accurately. The method is more accurate on a Core 2 CPU at idle compared to the traditional method of reading the EAX register of MSR 0x198. At full load when a CPU does not support IDA, both methods should be the same.
If you use this method for Core i then consider using it for Core 2 as well. The white paper method is a little complicated but it provides users with the most accurate look at what their CPU is really up to.
Last edited by unclewebb; 05-18-2010 at 06:54 PM.
Member of Overclockers.com Folding @ Home team
"<The_Coolest> you can't unwaste wasted CPU cycles" - Start FOLDing now!
Main rig:
AMD Ryzen 7 2700X / Mobo: Asrock Fatal1ty X470 / EVO 970 500GB + WD Blue 250GB + HDD / GPU: Dell RX 570 4GB / Mem: 2x16GB DDR4-3200 G.Skill 32GTZKW TridentZ - 32GB total / PSU: Seasonic Prime Ultra Gold 650W
Secondary rigs:
Core i7 2600K 3.4GHz @ 4.3GHz (Scythe Mugen2) / Mobo: Biostar TP67XE / 2x Inland Pro 120GB / GPU: HD5450 / Mem: 4x4GB DDR3-1600 G.Skill 8GBXL RipJawsX - 16GB total / PSU: Seasonic S12II 620W.
Core i3 540 3.06GHz @ 4.0GHz (Freezer 7 Pro) / Mobo: MSI H55M-ED55 / GPU: Integrated / Mem: 4x2GB DDR3-1600 G.Skill 4GBRL RipJaws - 8GB total / PSU: Antec 380W.
Core Temp - Accurate temperature monitor for Intel's Core/Core 2 and AMD64 processors
I just tried the 64 bit version, frequency is reporting correctly on my i950, windows 7 64bit now, tried with turbo on, turbo off, speedstep on/off and idle and load, all were correct.
Only two minor annoyances.
1) Every time when first start core temp, it reads 12 multi for 1 second, then reports the correct multi.
2) Bclk always reported as for example 169.99 instead of 170 or 159.99 instead of 160, and mhz will always read 3599 instead of 3600.
Sample pics:
Pic 1 is turbo on, idle, speedstep off
Pic 2 is turbo off, load, speedstep off
pic 3 is speedstep on, idle
Last edited by rge; 06-07-2010 at 05:57 AM.
Congratulations, your new algorithm is working excellent.
We can both thank rge because he's the guy that originally sent me the Intel Turbo White Paper a long time ago and helped me get this method working correctly on his original Core i7. Now all someone has to do is contact CPU-Z, Everest and HWiNFO32 and ask them to start using the Intel specified method. I recently asked the programmer of HWiNFO32 to consider following the Intel method but at the moment, he is sticking with his own method.
I tried Core Temp in a variety of situations and I found that it is 100% better than the previous version and only noticed one minor problem on my T8100 mobile CPU.
The mobile chips can use Super Low Frequency Mode (SLFM) at idle. On the T8100, this actually boosts the multiplier from 6.0 to 8.0 and then internally drops the bus speed from 200 MHz to 100 MHz so at idle the total MHz should look like this:
100.0 X 8.0 = 800.0 MHz
The Intel timer method was not intended for Core 2 CPUs so I decided to cheat a little and report the above as:
200.0 X 4.0 = 800.0 MHz
CPU-Z has decided to report the same thing. Technically speaking, this is not correct but at least we both get the total MHz right. HWiNFO32 is able to report this correctly but isn't always accurate at reporting IDA or turbo boost correctly when it is rapidly changing.
If you are using a low multiplier cut off filter in your code then all you have to do is lower that filter and using the Intel timer method, it will be able to report like CPU-Z does. When SLFM mode is rapidly engaging and disengaging, accurately reporting this using the timer method might not be possible. I didn't look into this too much since the total MHz is accurate and shows me what I wanted to know. If you don't have a laptop to test on and you want to try fixing this up then just post a new version and I'll let you know how it works.
The newer Core 2 mobile chips that use a 266MHz bus speed do this internally when SLFM mode is being used:
133.0 X 6.0 = 798.0 MHz
CPU-Z and RealTemp report this as:
266.0 X 3.0 = 798.0 MHz
It's also possible to manipulate the T8100 by changing MSR 0x199 so it can use this same multiplier:
100.0 X 6.0 = 600.0 MHz
200.0 X 3.0 = 600.0 MHz
but this isn't mentioned in the Intel docs that I've read.
Good work.![]()
Last edited by unclewebb; 06-07-2010 at 11:02 AM.
Thanks for your testing and input. It's appreciated.
I've removed the lower limit of x6 and I've improved the on the fly FSB detection algorithm. (Removing the lower limit will result in a strange frequency value at the first 1-3 seconds and should correct itself afterward)
Could you redownload it and see how it reads your CPU at idle now?
You would need to go to Options --> Settings and enable the on the fly bus detection.
Member of Overclockers.com Folding @ Home team
"<The_Coolest> you can't unwaste wasted CPU cycles" - Start FOLDing now!
Main rig:
AMD Ryzen 7 2700X / Mobo: Asrock Fatal1ty X470 / EVO 970 500GB + WD Blue 250GB + HDD / GPU: Dell RX 570 4GB / Mem: 2x16GB DDR4-3200 G.Skill 32GTZKW TridentZ - 32GB total / PSU: Seasonic Prime Ultra Gold 650W
Secondary rigs:
Core i7 2600K 3.4GHz @ 4.3GHz (Scythe Mugen2) / Mobo: Biostar TP67XE / 2x Inland Pro 120GB / GPU: HD5450 / Mem: 4x4GB DDR3-1600 G.Skill 8GBXL RipJawsX - 16GB total / PSU: Seasonic S12II 620W.
Core i3 540 3.06GHz @ 4.0GHz (Freezer 7 Pro) / Mobo: MSI H55M-ED55 / GPU: Integrated / Mem: 4x2GB DDR3-1600 G.Skill 4GBRL RipJaws - 8GB total / PSU: Antec 380W.
Core Temp - Accurate temperature monitor for Intel's Core/Core 2 and AMD64 processors
That fix is working.
MSR 0x198 shows 0x06008813 in the EAX register. The first 8 shows that SLFM mode is active and the next 8 is the 8X multiplier. Based on this, the effective average multiplier is equivalent to 4.0.
When lightly loaded, the SLFM bit in this MSR can be switching on and off rapidly so I find it makes more sense to just report 4.0 or whatever the calculated multiplier comes out to using Intel's method.
When I adjusted my CPU to use the 6.0 multiplier with the SLFM bit set, Core Temp and CPU-Z both report 3.0 so everything looks good.
I also did a test of Intel Dynamic Acceleration mode. On the T8100 when one core is asleep with the 10.5 multiplier, the other core can use the 11.5 multiplier. Core Temp correctly reports 11.5.
I did another test on a QX CPU and I adjusted the multiplier higher than what I booted up at and Core Temp reported the change correctly.
If you've got the Intel method working this good on Core 2, it should work great on any of the newer Core i CPUs.
Cool, thanks.
One last question, did you try to turn on on the fly fsb detection?
Member of Overclockers.com Folding @ Home team
"<The_Coolest> you can't unwaste wasted CPU cycles" - Start FOLDing now!
Main rig:
AMD Ryzen 7 2700X / Mobo: Asrock Fatal1ty X470 / EVO 970 500GB + WD Blue 250GB + HDD / GPU: Dell RX 570 4GB / Mem: 2x16GB DDR4-3200 G.Skill 32GTZKW TridentZ - 32GB total / PSU: Seasonic Prime Ultra Gold 650W
Secondary rigs:
Core i7 2600K 3.4GHz @ 4.3GHz (Scythe Mugen2) / Mobo: Biostar TP67XE / 2x Inland Pro 120GB / GPU: HD5450 / Mem: 4x4GB DDR3-1600 G.Skill 8GBXL RipJawsX - 16GB total / PSU: Seasonic S12II 620W.
Core i3 540 3.06GHz @ 4.0GHz (Freezer 7 Pro) / Mobo: MSI H55M-ED55 / GPU: Integrated / Mem: 4x2GB DDR3-1600 G.Skill 4GBRL RipJaws - 8GB total / PSU: Antec 380W.
Core Temp - Accurate temperature monitor for Intel's Core/Core 2 and AMD64 processors
I just gave "on the fly FSB" a try but I find that it is too inefficient. It puts too much load on the CPU. On my laptop, task manager is showing the load jump back and forth constantly between 0% and 15% or so when this option is turned on and Core Temp CPU Usage is next to nothing when it is turned off.
One thing that rge mentioned and I noticed is that when Core Temp first starts, it initially reports a very low multiplier like 0.5 on my T8100. What I do in my code is I immediately make sure the timers (0x30A, 0x30B) are turned on and I sample them basically at the same time. When I sample the timers again one second later, they provide me with very accurate information so I can immediately determine an accurate multiplier and display it. You don't even have to wait a full second for them to give you very accurate results.
http://www.codeguru.com/forum/showpo...1&postcount=10
When calculating MHz, I use QueryPerformanceCounter() before and after a tight loop of a mindless calculation something like this:
you would also need a rdtsc before and after that loop so you can calculate the MHz. Since this loop does absolutely nothing, some optimizing compilers will delete this code. x will always be equal to zero after this calculation so the if ( x== 0 ) part might help trick the compiler into thinking that this calculation is important enough to keep. Play around with the 10000 number. I use more than that but don't do this calculation very often. You might get excellent results with this method with a lot less CPU load and you might be able to combine this method with measuring the speed of the core timer or some other method you use.Code:QueryPerformanceCounter( &StartTime ); int x = 123456789; for ( int nLoop = 0; nLoop < 10000; nLoop++ ) x = x / 7; if ( x == 0 ) QueryPerformanceCounter( &EndTime );
When overclocking using SetFSB, the internal timers can get screwed up in Windows XP but I think Vista and Windows 7 automatically correct for this. It gets stupid sometimes trying to get accurate time and accurate MHz out of a Windows based computer. Boards that drop the Core 2 bus speed at idle for energy saving purposes can also screw things up. It's always a balancing act between accuracy and loading the CPU to determine what speed it's really running at.
Last edited by unclewebb; 06-08-2010 at 09:50 AM.
Hi guys,
yes, I still stick with the old method since I want to avoid some kind of averaging when measuring differential across more P-States. Moreover, you need some tricks (like for SLFM, XE), which I somehow don't likeIt's my private opinion... I know the method is not perfect especially in 2 cases:
- Turbo on certain NMH CPUs (my measurement can cause the CPU core to engage Turbo)
- Clock modulation
but I still keep the hope to tune this somehow.
Mumak: There are advantages and disadvantages to every method and no matter what method you use, you will always have to use some tricks to try and report data that accurately reflects what the CPU is really up to. Intel has made a lot of improvements to the Core i CPUs so they don't have the same monitoring issues that the previous Core 2 CPUs have. That's why I wouldn't use anything but the calculated multiplier method for newer Core i CPUs. Hopefully someday Intel increases these timers to 64 bit instead of 40 bit and locks them so no software can randomly write to them or reset them. Once Intel does that, those timers will be perfect.
The Coolest: I'm going to try reading bit[15], SLFM bit, in MSR 0x198. It should be easy to modify the calculated multiplier X2 and divide the bus frequency by 2 so this method is more technically accurate when SLFM is being used.
Edit: Doing that seems to work good and reports what the CPU is really doing when SLFM mode kicks in. The multiplier goes up on this T8100 and the bus speed gets cut in half.
![]()
Last edited by unclewebb; 06-09-2010 at 09:58 AM.
That is actually something I thought of doing as well, nice idea. I think I'll implement it as well, as it requires no real work to do this.
Also I have updated Core Temp (same links as before) regarding the low frequency reading on launch. I only have tested it on a few desktop C2Ds.
Would appreciate someone with a Core i series CPU to test it as well.
32 Bit
64 Bit
*EDIT: And I added support for the SLFM bit. Simply divide the FSB speed by 2 if the bit is set.
Last edited by The Coolest; 06-09-2010 at 10:42 AM.
Member of Overclockers.com Folding @ Home team
"<The_Coolest> you can't unwaste wasted CPU cycles" - Start FOLDing now!
Main rig:
AMD Ryzen 7 2700X / Mobo: Asrock Fatal1ty X470 / EVO 970 500GB + WD Blue 250GB + HDD / GPU: Dell RX 570 4GB / Mem: 2x16GB DDR4-3200 G.Skill 32GTZKW TridentZ - 32GB total / PSU: Seasonic Prime Ultra Gold 650W
Secondary rigs:
Core i7 2600K 3.4GHz @ 4.3GHz (Scythe Mugen2) / Mobo: Biostar TP67XE / 2x Inland Pro 120GB / GPU: HD5450 / Mem: 4x4GB DDR3-1600 G.Skill 8GBXL RipJawsX - 16GB total / PSU: Seasonic S12II 620W.
Core i3 540 3.06GHz @ 4.0GHz (Freezer 7 Pro) / Mobo: MSI H55M-ED55 / GPU: Integrated / Mem: 4x2GB DDR3-1600 G.Skill 4GBRL RipJaws - 8GB total / PSU: Antec 380W.
Core Temp - Accurate temperature monitor for Intel's Core/Core 2 and AMD64 processors
Another topic: Are you aware of the DTS inaccuracy issue especially on pre-Nehalem CPUs? Certain families have such bad accuracy that a temperature below a certain threshold doesn't mean a concrete temperature, but just a temperature below this threshold. So in my opinion values around room temperature are useless for certain families. The best accuracy is @ Tj,max and gets worser the farther the distance to Tj,max is.. The threshold on some families is @ 50 C.
Yes I noticed. This is especially bad on the Wolfdale chips and derivatives. Nothing we can really do about it.
Member of Overclockers.com Folding @ Home team
"<The_Coolest> you can't unwaste wasted CPU cycles" - Start FOLDing now!
Main rig:
AMD Ryzen 7 2700X / Mobo: Asrock Fatal1ty X470 / EVO 970 500GB + WD Blue 250GB + HDD / GPU: Dell RX 570 4GB / Mem: 2x16GB DDR4-3200 G.Skill 32GTZKW TridentZ - 32GB total / PSU: Seasonic Prime Ultra Gold 650W
Secondary rigs:
Core i7 2600K 3.4GHz @ 4.3GHz (Scythe Mugen2) / Mobo: Biostar TP67XE / 2x Inland Pro 120GB / GPU: HD5450 / Mem: 4x4GB DDR3-1600 G.Skill 8GBXL RipJawsX - 16GB total / PSU: Seasonic S12II 620W.
Core i3 540 3.06GHz @ 4.0GHz (Freezer 7 Pro) / Mobo: MSI H55M-ED55 / GPU: Integrated / Mem: 4x2GB DDR3-1600 G.Skill 4GBRL RipJaws - 8GB total / PSU: Antec 380W.
Core Temp - Accurate temperature monitor for Intel's Core/Core 2 and AMD64 processors
The Coolest: I noticed one problem.
When the CPU switches into or out of SLFM mode rapidly, sometimes the calculated multiplier will be high even though the SLFM bit in MSR 0x198 is set. To avoid doubling this and reporting a sky high multiplier that is not physically possible, I just added a filter to this data. If the result after doubling is going to be greater than the maximum possible multiplier for that CPU then I avoid doing the times 2, divided by 2 trick and just leave the data as is.
Other than that, it looks OK. No more 0.5 multipliers when Core Temp first starts. Getting this method to work correctly on Core 2 takes some work but if you followed the method in the turbo white paper then this should work correctly on the Core i CPUs. rge's testing proves that.
Bookmarks