1. Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

RealTemp General Discussion

Discussion in 'RealTemp' started by unclewebb, Jun 28, 2008.

  1. Mussels

    Mussels Moderprator Staff Member

    Joined:
    Oct 6, 2004
    Messages:
    42,981 (11.07/day)
    Thanks Received:
    10,292
    assuming you arent the clumsy type, do a finger-walk of the nearby components. if you cant hold your finger on it for 30 seconds, its too hot - cool it :)
     
  2. somebody

    somebody New Member

    Joined:
    Sep 28, 2009
    Messages:
    127 (0.06/day)
    Thanks Received:
    27
    Not sure if it's been mentioned before but RealTemp doesn't seem to pick up the SLFM on mobile Core 2 Duo's (bit 15 [EAX] of MSR 0x198) This doesn't seem just related to RealTemp as you can see below, error in red, good in green. CPU-Z will display the correct frequency using the calculated method with F9 as shown but not using the multiplier.

    i7Turbo is great although it wont show any calculated multi less than 6 but above that it seems fine. Only wish I had an i7 to play with :ohwell:

    The screenshot shows RT ver 3.00 but I also got the same result with 3.30

    Using 10x multi with SLFM (5x multi effective = 1.67GHz)
    [​IMG]

     
    Last edited: Sep 28, 2009
  3. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    996 (0.39/day)
    Thanks Received:
    462
    somebody: I really appreciate users that step forward and clearly show when there is a problem.

    I wish I had one of every CPU for testing purposes but unfortunately Intel doesn't send me anything.

    i7 Turbo has a lower filter of 6 for Core 2 Duo CPUs. Obviously on a P8400, that's wrong.

    RealTemp 3.30 has an INI option to use the same multiplier calculation method that i7 Turbo uses. If you go into the INI file and add this:

    AverageMulti=1

    that should calculate the multiplier the same as i7 Turbo does but it likely has the same problem with the minimum being reported as 6 instead of the correct 5. I'm just in the process of giving RealTemp a work over so hopefully later this week it will be all fixed up. Thanks for your help.

    Edit: I'm not sure if that INI file option is working in RealTemp 3.30. :eek:
    It used to work. I will be transferring the i7 Turbo code back into RealTemp in the near future.
     
    Last edited: Sep 29, 2009
  4. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    996 (0.39/day)
    Thanks Received:
    462
    http://www.fileden.com/files/2008/3/3/1794507/Turbo.zip

    I updated i7 Turbo to version 6.9 which shouldn't have the low multi filter anymore. Hopefully you can give that a try somebody and post your results. If it works I'll get RealTemp updated later this week. The RealTemp code is presently in a big mess. :(

    Edit: Can you post a link or a screen shot of any documentation you have about MSR 0x198 bit[15]? It's not explained very well in the Intel documentation I have.

    You could also post a screen shot or two of this MSR with and without SLFM enabled.

    Here's a link to my MSR tool. Just enter 0x198 and click on Read MSR.

    http://www.fileden.com/files/2008/3/3/1794507/MSR.zip
     
    Last edited: Sep 28, 2009
    somebody says thanks.
  5. SuperJoker New Member

    Joined:
    Sep 27, 2009
    Messages:
    24 (0.01/day)
    Thanks Received:
    0
    Location:
    Yermo, CA
    It looks the same as 6.8 and in the other thread I tried adding a few posts, 4 at last count and I'm getting moderated, I'd like to know Why please?
     
  6. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    996 (0.39/day)
    Thanks Received:
    462
    Version 6.9 is to fix the problem that somebody showed above. If you are having trouble posting on TechPowerUp then send me an email to

    real_temp@yahoo.ca

    You can send pictures directly there. If i7 Turbo 6.9 shows only two cores on your ES CPU then it will be easier for me to switch that program back to non UNICODE to see if that makes a difference. The problem you are having might not be UNICODE related as I've changed 1001 things since RealTemp 2.70. So far I've learned that doing things by the book (the Intel books) usually causes more problems than what it's worth. Things worked better before when I didn't read any manuals and just winged it. :)
     
  7. SuperJoker New Member

    Joined:
    Sep 27, 2009
    Messages:
    24 (0.01/day)
    Thanks Received:
    0
    Location:
    Yermo, CA
    Ok.
     
  8. somebody

    somebody New Member

    Joined:
    Sep 28, 2009
    Messages:
    127 (0.06/day)
    Thanks Received:
    27
    I certainly can understand that, I only have the Core 2 Duo and can not justify the expense of buying new systems just to see how the other CPU's work as much as I'd like too.

    i7Turbo 6.9 now recognises calculated multipliers below 6.0, nice job BTW. RealTemp 3.30 when using option AverageMulti=1 does not calculate below 6.0 as you suspected but otherwise okay :)

    As far as the Intel MSRs go it's pretty much empirical data and as the name suggests probably very 'model specific' except for perhaps the architectural ones. Not sure if this helps you as you probably know most if not all here already but maybe it will be of use to others.

    From P8400
    Multipliers 6.0x to 8.5x
    IDA 9.0x
    SLFM

    [​IMG]
    FID = Multiplier
    VID = CPU Voltage

    From the above data we can see in MSR 0x199 we have requested a 9.0x multiplier at 1.2000V (0927) but from MSR 0x198 we are currently using 8.5x multiplier at 1.1375V (4822).

    Speculative Notes
    • SLFM has to be enabled by bit 28 in MSR 0xEE to work.
    • IDA is enabled by setting bit 38 of MSR 0x1A0 to 0.
    • The ? bit 32 in MSR 199 seems to disable IDA ???
    • Half multipliers can not be used at the same time as SLFM
    • The 6.5x multiplier cannot be selected :confused:
    • Don't seem to be able to use SLFM above the 16x multiplier.
    • The 'Current Minimum VID' in MSR 0x198 may not be valid when SLFM is enabled.
    • Once LOCK bit 20 of MSR 0x1A0 has been set, bit 20 and EIST bit 16 can not be changed.

    When I first read about the Intel DTS Core sensors I imagined them being super accurate but was disappointed. When preparing to replace the TIM on the CPU for overclocking purposes I decided after booting up to put the CPU into it's lowest FID:VID and without to many programs running carefully pulled off the heatsink. Using an infrared thermo-scope the CPU case measured almost 10C higher than the cores up to 60C. I did want to test higher as I beleive they're supposed to be most accurate around 90C but I got a bit too enthusiastic and increased the CPU work load too quickly resulting in the ACPI shutting down the system before I could take anymore measurements. :eek: As I was more interested in getting the overclock to work at that time I didn't try again. The strange thing is although the DTS accuracy was off, the ACPI CPU temperature agreed degree for degree for what should have been the correct core temperature up to the 60C that was measured.

    You can see the difference in the cores and ACPI CPU temperature in this overclocking post
    http://forums.overclockzone.com/forums/showthread.php?p=10357153#post10357153
    and may find it interesting for other reasons than temperature ;)
     
    Last edited: Oct 3, 2009
    unclewebb says thanks.
  9. Doctor Lo

    Doctor Lo New Member

    Joined:
    Sep 29, 2009
    Messages:
    2 (0.00/day)
    Thanks Received:
    0
    Location:
    Madrid, Spain
    Temps on Q6600

    First of all this is my first post so I´d like to say Hi to everyone. I´m new to overclocking but I´ve been reading about it for a while.. I just haven´t had the time to get to do it until now. I´ve been also reading about core temperature apps... and since I didnt really get a conclusion on which one is best, I chose what I liked the most, (which is obviously RealTemp). I´m going through the documentation an I´ve already have a question about one of the first steps:

    I have a Q6600 stepping G0. Temp in front of my antec nine hundred is 25,2C (im getting a second thermometer this afternoon though). The OS is Windows 7 Professional 64 bits.


    When doing the Sensor test I get the following temperatures:

    [​IMG]


    Then from what I read in the documentation
    Which matches to what happened to me... does it mean I should change TJMax ??? Cos I´m quite sure I´ve also read on this thread that it shouldnt be changed!!!! And thats actually what confuses me. If so.. its 105 and 105 for cores 2 and 3, right ?

    Thanks for reading !!
     
  10. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    996 (0.39/day)
    Thanks Received:
    462
    Doctor Lo: I was reading through some documentation for the new i7-920XM mobile processors and for the first time I finally read a hard number about the amount of error their sensors have at TJMax.

    [​IMG]

    Finally a number that confirms my theory that TJMax is not written in stone. Based on my testing, I think the original Core 2 CPUs like your Q6600, have a similar amount of error. The 45nm Quads seem to use up this entire range and TJMax can vary from 100C to 110C. Maybe a year or two from now Intel will come clean and also admit that they do this deliberately to better control thermal throttling so all 4 cores don't reach the throttling point at the exact same time. Just a theory I have.

    Looking at your numbers I would do a nice, simple calibration fix by setting TJMax = 100, 100, 105, 105. The slope of the 4 temperature curves are very similar so I wouldn't bother changing anything else or using any of the other RealTemp calibration factors. You should now have 4 cores that will report very similar temperatures when equally loaded with a program like Prime95 Small FFTs from idle to TJMax.

    Thanks somebody for that chart. I have no idea why Intel makes programmers do infinite trial and error testing or jump through other hoops like signing NDA agreements just to get basic information like you've provided. It drives me crazy but it is fun when you discover something new. :)

    I found out where the half multi flag was hiding in MSR 0x198 and 0x199 but I didn't know about the SLFM flag. Too bad Intel removed VID information from 0xCE in the Core i7 CPUs.

    i7 Turbo determines the multiplier based on two high performance timers for each thread or core which is the Intel recommended method but it's nice to know about the SLFM bit too.

    If you have time, can you post what i7 Turbo shows when running a single thread of Super PI and also when running two threads of Super PI. Hyper PI is a nice front end for running 1 or multiple threads of Super PI mod 1.5.

    I don't think it will report the full 9.0X multi on your chip. On other CPUs that support Intel Dynamic Acceleration, it usually reports something like 23.8 on a Core i5-750. On this CPU, any background activity that kicks in drops it to the lower multiplier when more than 2 cores are active and i7 Turbo shows this pretty clearly. One user with a T9500 tested this and got similar results where it's impossible to get the full maximum IDA multi continuously unless you disable one core in the bios which usually isn't possible on most laptops.

    Your findings that below 60C, the core sensors can move at a significant slope compared to a change in actual core temperature is the same thing I found when I pointed my IR thermometer at the IHS. This problem seems worse with the 45nm Core 2 based temperature sensors.

    Nice modded laptop. I wish I could do the same on my wife's laptop but I think she'd frown when the soldering gun came out. :toast:

    [​IMG]

    The T9500 has a default multi of 13 and when running a single threaded app and IDA kicks in, it can cycle up to 14. This cycling between 13 and 14 happens continuously hundreds of times a second so i7 Turbo reports the average multiplier during each 1 second interval. You can see that the core that is doing the majority of the work is able to use the 14X multiplier the majority of the time (~72.8%) but it will never be able to use the 14X multiplier the entire time because there will always be some background process that needs to be serviced by the second core which immediately drops the multiplier back to 13X. Maybe your modded P8400 will be able to get around this Intel limitation. :)
     
    Last edited: Sep 30, 2009
  11. somebody

    somebody New Member

    Joined:
    Sep 28, 2009
    Messages:
    127 (0.06/day)
    Thanks Received:
    27
    I think 0xCE is very model specific as I seen reference to FSB for it as well.


    Would you like it run as a normal system or with the IDA bug or both?


    That's nice, I only get an extra 0.5x multi on the P8400 but maybe the BUS clock is higher than the T9500


    I found some more problems.
    [​IMG]
    Green=Right, Red=Wrong. Ran with IST off and fixed 6.0x multi.
    I should have put the red RT under the red i7Turbo, sorry if it's confusing.

    When I run RealTemp 3.00 or 3.30 or i7Turbo 6.9 with IDA (Turbo Mode) enabled and no load it seems to calculate/measure the BUS frequency incorrectly 314MHz as apposed to 333MHz. The incorrect calculated multi in i7Turbo then seems to be (333.3/314.78 * 6.0). Strangely enough 333.33/314.78 seems pretty close to 9.0/8.5, the IDA multi and top full load multi. If I put a load on the CPU (only tried 100%) and then run the programs they give the correct BUS and multipliers. If I disable IDA then run the programs with or without load they work correctly. It also seems once the initial BUS frequency is calculated/measured then while the programs are running correctly IDA can be enabled and the programs still show the correct readings. I guess the initial calculation is a one time thing and doesn't change unless the programs are restarted. While running RT 3.30 with the incorrect 314MHz BUS, a 7.0x multi and 'AverageMulti=1' it rounds up to show 7.5x. Hope this all makes sense in some way.

    Something I forgot to mention in the last post was that the 'Turbo Mode Disable' check box does not update if the setting is changed externally by another program unlike the 'EIST' check box. The 'EIST' check box remains grayed out regardless of the lock bit, you probably meant for it to be that way but thought I'd better mention it just in case.
     
    Last edited: Sep 30, 2009
  12. Doctor Lo

    Doctor Lo New Member

    Joined:
    Sep 29, 2009
    Messages:
    2 (0.00/day)
    Thanks Received:
    0
    Location:
    Madrid, Spain
    Thank you very much unclewebb !!! That will actually save me lots of time (time working.. and time wondering).

    I´ve set it TJMax 100, 100, 105, 105 and temperatures are within 1 degree in all the 4 cores all the time (for example, when heating up and running the cool down test). So I guess its good news :)
    I just feel now that it gets a bit too hot for an stock cpu with an aftermarket cooler... but thats another topic !



    :toast:
     
  13. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    996 (0.39/day)
    Thanks Received:
    462
    http://www.fileden.com/files/2008/3/3/1794507/Turbo691.zip

    This is starting to make more sense. I think my assumption that IDA mode on the Core 2 mobile CPUs is just like Turbo mode on Core i7 CPUs is not quite right. The default maximum multiplier never changes on a Core 2 Duo Desktop chip or Core i7 so my code only calculates this once. I think that this value must change when IDA mode is toggled on and off so I need to recalculate this value while the program is running. Seeing that the errors are perfect ratios of either 9.0/8.5 or 8.5/9.0 makes it easy to see what is likely going on.

    I left the EIST box grayed out for two reasons. On my E8400, the lock bit is set and it is a R/WO bit (read / write once) so I've never been able to unlock this to try and toggle EIST. When tested on a Core i7, it was possible to toggle the EIST flag but the actual SpeedStep status of the processor didn't seem to change. I decided to just report the status of the EIST flag in bit[16] in this box and not allow users to try and change it because of the above.

    What software do you use to toggle EIST? Maybe if I tested the Lock bit first and saw that it was unlocked, then I could open this feature up and give a user the option to toggle EIST. Do you know if the Lock bit is set to zero on your CPU when you first boot up?

    I fixed i7 Turbo so the Disable Turbo Mode flag gets updated on a regular basis in case a second program changes this so it should work similar to the C1E flag now. Thanks for noticing that. Trying to develop this program on my E8400 has led to an over sight or two like that. Help from users with a variety of CPUs is most appreciated and saves me lots of this $$$$$.

    I usually try to stick to MSR registers that are fully documented for the Core 2 Duo to try and support as many CPUs as possible. There's a lot of model specific info hiding in different places in these CPUs but as you know, it doesn't always apply across the board. That's why I try to avoid MSR 0xCE.

    The updated version of i7 Turbo is a wild stab in the dark. If it works correctly now, it's more luck than by design. :)

    If it doesn't work correctly could you use my MSR Tool and show me what's hiding in:

    MSR 0x2A
    MSR 0x198

    with IDA enabled and disabled. Those two MSRs are well documented for Core 2 Duo so I'm hoping I can find the necessary info in there. The Calculated Multiplier method I'm using was originally documented for Core i7 CPUs and seems to work 100% correctly for them and the new Core i5. With a few tweaks I've been able to get it working for most Core 2 Duo CPUs that I've tested but it still needs one more tweak to handle IDA mode correctly.

    I appreciate any help you can send my way. No need to include RealTemp in the screen shots. That's a work in progress. Once I get the multipliers sorted out then I can go back and add this new code directly into RealTemp.

    Edit: I read about Dynamic FSB Frequency Switching technology in the Core 2 Mobile Datasheet:

    [​IMG]

    I'm not yet sure if software will be able to correctly display the FSB when this happens or what the real FSB is when this happens. Some software might continue to report the external FSB when internally the CPU could be running at half that speed. I'm also not sure how this relates to the multiplier dropping in half during SLFM. Maybe SLFM can cause a drop in FSB or a drop in the multi depending on the CPU but not both on the same CPU. Always lots to learn.
     
    Last edited: Sep 30, 2009
  14. somebody

    somebody New Member

    Joined:
    Sep 28, 2009
    Messages:
    127 (0.06/day)
    Thanks Received:
    27
    Whatever is at hand and easy to use, including at times my own erm, programs. "RW Everything" offers some useful access to hardware but I'm a bit reluctant to use it for writing MSRs as it occasionally gives BSODs on my system.


    This depends on the BIOS, for me a normal boot will result in EIST enabled and locked. Disabling P-States in the BIOS naturally leaves EIST off and unlocked. I guess it's possible for a BIOS to lock EIST off but that would really suck IMHO.


    Can't argue with that. I wonder though if in my specific case I should call absolute max and min as shown in the previous MSR chart I posted, IDA and SLFM FID:VIDs as I notice with Intel data a lot of the SLFM frequencies are 800MHz and AFAIK for the T7100 for example this would mean having to use an 8.0x multi with the half BUS clock (4.0x effective) wheras a 6.0x multi is available for the full BUS clock.


    While on load it appears to work fine but during low loads it occasionally gives the incorrect reading. See attached log files.

    MSR 0x2A 00000000:49880800 This typically reflects multiplier by bits 26:22 and halves by bit 18 with or without IDA.

    MSR 0x198 06170927:06000617 with IDA, 06174822:0600617 without IDA. Note however with IDA enabled the MSR will only show 0927 in bits 47:32 when one core is doing the work. If both cores are working then this will drop to 4822 (8.5x).

    AFAIK SLFM will halve the CPU frequency and the FSB. By running a RAM benchmark at 6.0x multi and then running again with a 12.0x multi but using SLFM to give an effective CPU 6.0x the RAM bandwidth is dramatically reduced. Everest seems to show this fairly well as per attachment.

    Had a bit of trouble with the log option, the buffer sometimes doesn't get written as expected i.e. the log check box doesn't seem to be linked to CreateFile / CloseHandle resulting in missed data.
     

    Attached Files:

    • logs.zip
      File size:
      245.7 KB
      Views:
      179
    Last edited: Oct 3, 2009
  15. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    996 (0.39/day)
    Thanks Received:
    462
    My MSR Tool works well. You can crash a computer if you randomly write values into the wrong MSR but if you have the Intel manuals handy and only write to where you should be writing to, then things are OK. A lot of MSRs seem protected and are read only so you can't write junk to them. I tried. :D

    My bios has a supposed option to disable EIST but when you boot up and actually look at MSR 0x1A0, you can see that the bios did not disable it and it is in a locked state so there's no way to change it. I think there are quite a few motherboards and bios versions out there that do this. Users assume that when they turn something off in the bios that it actually gets turned off but that's not always true.

    If 800 MHz is the correct SLFM frequency for a T7100 then I guess it must be dropping to 200 MHz X 4.0 which is different than your P8400 which can drop to a 3.0X multiplier. It's possible that the manuals aren't accurate and a T7100 also drops to 3.0X.

    I had a look at the log files and I think i7 Turbo is mostly working correctly. There are a couple of instances where it showed a brief overshoot and reported a multiplier like 9.2X which of course is impossible but other than that, I think what it is telling you at idle is actually very accurate.

    When i7 Turbo is not reporting a steady multiplier at idle and it is jumping up and down like a yo-yo, it's usually doing this for a reason. Internally your multiplier can be constantly jumping up and down and most software misses this.

    Software like CPU-Z simply samples MSR 0x198 once per second and reports that multiplier. The load CPU-Z puts on a CPU while sampling can force a CPU to the higher multiplier so it will report a nice steady multiplier number while internally the multiplier is jumping up and down hundreds of times a second. I believe that is what i7 Turbo is showing you.

    If you are using Vista or Windows 7, go into the control panel -> Power Options and play around with the Minimum processor state. For XP you may need to set it to mobile CPU, even for Desktop CPUs to get this working properly. If you drop this setting to a low number like 5%, this will typically get your actual multiplier to settle down to a steady 6.0. You might also have to adjust C1E and EIST. There seems to be times where the hardware and the software can't agree on what the multiplier should be set to when the CPU is idle so it will rapidly cycle back and forth between say 9.0X and 6.0X. i7 Turbo reports the average of this somewhere around 7.5X but it will be constantly jumping around this number based on background load and how much time it is spending at each multiplier. It also spends time at the intermediate multipliers between the Min and Max multis.

    When your log files show the calculated multiplier dropping down towards 3.00, that's a good sign that SLFM is working. As before, multipliers aren't always constant numbers like CPU-Z has led us to believe. The multiplier can be constantly transitioning as it heads towards idle or towards full power. The i7 Turbo average gives you a more accurate picture compared to a single snapshot of an MSR once per second.

    To me, the PI-1 IDA log looks OK except for one or two overshoots during transition that I mentioned before. It should be easy for me to get that fixed up.

    The PI-1 Norm looks interesting. i7 Turbo is reporting an average multiplier somewhere around 8.75. It shows the first core close to the IDA multi of 9.0 and the other core that is not running SuperPI is at 8.5 so the overall average makes sense. CPU-Z is reporting 9.0 which is correct for core 0. If you run two instances of CPU-Z and you right click on the first instance of CPU-Z and tell it to monitor Core #0 and then you right click on the second instance of CPU-Z and tell it to monitor Core #1, you will likely find CPU-Z is reporting 9.0X for one side of your CPU and 8.5X for the other core.

    I've seen this happen with a Q6600 desktop CPU where there was a problem with the bios. The first two cores would run with a 9.0X multi at full load but the other two cores were being limited to only 6.0X. CPU-Z was reporting the full 9.0X which was true for the core that it was reading. One user was scratching his head why i7 Turbo was only reporting an average of 7.5 and I too did some head scratching that day. It wasn't until I used that CPU-Z trick to monitor cores individually that it all started to make sense.

    The MSR column in the log file reads the multiplier from the MSR for each core and then averages them. It is reporting 8.75 at full load which confirms one core at 9.0 and the other at 8.5.

    Reading the multiplier by reading a single MSR is always a compromise. There are two things you can do to try and improve things but both methods have issues. If you write some code and you simply read the MSR multiplier, the act of reading this value usually causes the multiplier to jump up to its higher state just as you read it. The multi might be idle 99.999% of the time at 6.0 but every time you wake it up and read it, the multi jumps up and reports it's at 9.0X. One trick that is often times used is just before you read the multiplier you do a Sleep(1) and let the CPU settle down a bit. The goal is to try and read it by sneaking up on it and not disturbing it too much. The problem with this method at idle is that it tends to underestimate the multiplier and will report a steady 6.0X even though the multiplier can be jumping around. All software uses one of the two methods or some slight variation of the above but no matter what you do, there is no 100% accurate way to determine the multiplier by reading this MSR. It just gives you a snapshot of the multiplier at that one particular instance in time.

    Back to the logs. PI-2 IDA shows both cores fully loaded and that you are getting the full 9.0X multiplier on both cores. CPU-Z says 9.0, i7 Turbo shows 9.000 on both cores and the MSR multiplier in the log file also shows that both cores are reporting the full 9.0X multi. Given that IDA or turbo boost on this CPU is only an extra multiplier of 0.5, it looks like it is capable of running this full time. Core i7 CPUs can drop the turbo boost on some motherboards if they start running too hot and your CPU is likely the same. You might be able to see this since your CPU has been tweaked a little. The other two factors on a Core i7 that effect this are current flow and power consumption of your CPU. Any of these 3 factors can disable turbo boost until the CPU gets within spec again. I'm not sure how advanced the Core 2 mobile CPUs are when turbo throttling.

    A T9500 that has the possibility of a full +1.0 multiplier turbo boost doesn't give you the full boost when both cores are fully loaded. Interesting. The idle multiplier jumping up and down is accurately telling you what's going on. The MSR multiplier in the log is being reported as 6.0 because I'm obviously doing a Sleep(1) just before reading it so it has a chance to settle down. CPU-Z will typically report a solid 8.5 or 9.0 when this is going on but I believe that's about as accurate as reporting 6.0. Neither value is truly accurate if the multiplier is constantly changing back and forth between 6.0 and 9.0.

    PI-2 Norm with no IDA shows the correct 8.5X at full load. The log file shows at full load both it and the MSR reporting the same.

    I apologize about the log file. I'm a bit anal about writing things to the hard drive all the time when testing so I think I cache data and only write it out once per minute or when you exit the program. I'll have a look at that. When sampling, I try to create as small a foot print as possible so the act of sampling is changing the results as little as possible. Use a program like Process Explorer and you'll be able to see how big an elephant CPU-Z is when sampling. The load it creates sometimes hides the truth. :)

    Thanks for your help with this. Try playing around with EIST / C1E and the Minimum processor state and see how they effect the calculated multiplier at idle. I'm hoping you will be able to see the Calculated Multiplier settle down to 6.0 or close to it at idle and 3.0 when SLFM kicks in. When all power saving features are in agreement, it usually lets the CPU settle down and do its thing.

    I tried to access your website but Avast flagged it as having a Trojan. Likely BS but I didn't look into it too much. I have to keep my computer clean because I haven't properly backed it up in the last year or so. Typical.

    Edit: I was just wondering, can you set the SLFM bit in MSR 0x199 and force your computer to use use this mode even when fully loaded? On my E8400 I can use this MSR to set the half multi but SLFM isn't supported.
     
    Last edited: Oct 1, 2009
  16. somebody

    somebody New Member

    Joined:
    Sep 28, 2009
    Messages:
    127 (0.06/day)
    Thanks Received:
    27
    Unclewebb, all tests were done with IDA enabled and the files named as follows,
    • PI for SuperPi
    • 1 or 2 for the number of threads run
    • Norm for a normal configuration of EIST enabled, SLFM enabled and IDA enabled.
    • IDA for running with the hardware bug that enables IDA to be run full time at 100% load on both cores. This is of course contrary to Intels specification for IDA.
    As you can see with the normal (Norm) configuration with IDA enabled, when both cores are loaded the multiplier drops down to 8.5 on both cores as per Intels specification of IDA. As also shown on the overclocking link posted earlier the full time IDA worked with IntelBurnTest up to 94C still giving 19.5Gflops and no sign of dropping the 9.0x multi. With 8.5x on both cores I only get 18.4Gflops. Hopefully I will get to test if something like the IDA bug also exists with some of the later chips but knowing Intel and the fact that they have some very smart people working there I would imagine it's been silently fixed. Could be useful for overclocking and benchmarking if not.

    For someone who is spending their time and effort to produce some great free software there really is no need to apologize, now your making me feel bad for bringing up problems.

    Read this next bit very carefully, I do NOT have a website, what ever is trying to direct you to one is quite likely malware, please take care.

    Yes, I can set and use SLFM with full load using 6x to 16x multipliers (no halves) which is 3x to 8x effective.
     
  17. pantherx12

    pantherx12 New Member

    Joined:
    Jan 2, 2009
    Messages:
    9,714 (4.16/day)
    Thanks Received:
    1,699
    Location:
    ENGLAND-LAND-LAND
    Can realtemp be made easier to boot on OS load up?

    I've tried several different ways but it won't load consistently.
     
  18. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    996 (0.39/day)
    Thanks Received:
    462
    pantherx12: Here's one method that works with Windows 7 and it should work with Vista too.

    http://www.xtremesystems.org/forums/showpost.php?p=3970161&postcount=3657

    I'm using Vista x86 at the moment and I have Administrator privileges on my account so I just dragged a link to RealTemp into my Startup folder and it starts up for me every time.

    C:\Users\user name\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

    The RealTemp folder needs to be located in a directory that you have read/write access to and all of the WinRing0 files, etc., have to be left inside that folder. After that just right click on RealTemp.exe and drag a link into the Startup folder. This method also works when using XP but the Startup folder is in a slightly different location.

    Give this a try and if you are still having problems let me know a few more details. Some systems get overloaded at boot up time and I think the WinRing0 driver might not get properly loaded which can prevent RealTemp from starting up correctly. If that's the problem, I probably won't be able to fix it since I didn't write that driver. You might be able to use a slight time delay in the Task Scheduler to work around this issue which gives the OS time to settle down.

    This is going to sound crazy somebody but I love hearing about problems. It's the only way I can find out when something needs to be fixed and the problem you brought up definitely needed to be fixed. I used to buy lots of CPUs but users helping out saves me a lot of cash.

    In your post you mentioned RW Everything 1.4. I followed the link and ended up on a page that Avast didn't like. Avast was complaining the other day about WinRing0.sys so I don't take it too seriously or worry too much. Avast is usually so quiet that most of the time I'm not sure if it's actually working. I wasn't trying to blame you or anything like that. Sometimes when you're joking in a forum it doesn't always come across that way. If it was your site, I just wanted to do you a favor and let you know.

    IDA seems to work correctly on the T9500. Have you tried any other P8400 CPUs? My friend has a laptop with this CPU so now I'm curious to see how IDA works on his computer.

    Did you have a chance to play with the Minimum processor state yet? Most users are surprised when a few adjustments can settle the i7 Turbo readings down at idle. I know I was surprised when I first saw this in action. Your help has made i7 Turbo better for laptop owners. I plan to add a couple of more things I learned about the EIST lock and SLFM back into i7 Turbo.

    Edit: i7 Turbo 6.92 is reading the SLFM bit so it's able to correctly report a multiplier of 3.0 at idle for both the Calculated Multiplier as well as the multiplier coming from MSR 0x198.

    The LOAD% column is actually the percentage of time that the CPU spends in the C0 state. It works the opposite of a traditional load meter. The more a CPU slows down and goes into the idle states, the higher percentage of time the awake core will have to work in the C0 state to process the background tasks because it is operating at a much lower frequency as the CPU idles down. A high number in this column on a mobile CPU is a good thing.

    Code:
      DATE     TIME  CMULTI STDEV  MSR  LOAD%  NOTES
    10/02/09 20:25:18 3.000 0.000 3.000 69.12
    10/02/09 20:25:19 3.000 0.000 3.000 69.42
    10/02/09 20:25:20 3.000 0.000 3.000 69.28
    10/02/09 20:25:21 3.003 0.001 6.000 67.35
    10/02/09 20:25:22 3.160 0.004 3.000 63.89
    10/02/09 20:25:23 3.240 0.010 3.000 67.43
    10/02/09 20:25:24 3.000 0.000 3.000 71.39
    10/02/09 20:25:25 3.000 0.000 3.000 71.63
    10/02/09 20:25:26 3.000 0.000 3.000 70.57
    10/02/09 20:25:27 3.000 0.000 3.000 72.69
    10/02/09 20:25:28 3.000 0.000 3.000 72.51
    10/02/09 20:25:29 3.000 0.000 3.000 70.94
    10/02/09 20:25:30 3.000 0.000 3.000 70.20
    10/02/09 20:25:31 3.000 0.000 3.000 69.35
    10/02/09 20:25:32 3.000 0.000 3.000 69.88
    10/02/09 20:25:33 3.000 0.000 3.000 70.71
    
    My simple load tester might come in handy when testing this stuff out.
    http://www.fileden.com/files/2008/3/3/1794507/LoadTester.zip

    You can run multiple instances of this and if you need to, you can use Task Manager to lock it to an individual core. It creates load without creating a lot of heat. Perfect for laptop testing.

    Here's what SLFM mode looks like and what CPU-Z shows. Thanks Stefan for the pic.

    [​IMG]

    The high C0% is a sign that this CPU has really idled down so the percentage of time the active core must work in the C0 state goes up at idle. As the MHz goes down both externally and internally, the CPU must work harder and harder to keep up with the background tasks. A hard working CPU at a slow speed improves efficiency and reduces heat and power consumption.
     
    Last edited: Oct 2, 2009
  19. somebody

    somebody New Member

    Joined:
    Sep 28, 2009
    Messages:
    127 (0.06/day)
    Thanks Received:
    27
    Unclewebb, here's some logs from 6.92, let me know if you need something more specific.
     

    Attached Files:

  20. pantherx12

    pantherx12 New Member

    Joined:
    Jan 2, 2009
    Messages:
    9,714 (4.16/day)
    Thanks Received:
    1,699
    Location:
    ENGLAND-LAND-LAND
    I've tried that method with a zero percent success rate, I can only assume because the program needs admin rights. But even doing it via the windows scheduler with admin rights only works say half of the time.

    Happens on several of my rigs, Xeon x4 3220 and Phenom x2 be.
     
  21. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    996 (0.39/day)
    Thanks Received:
    462
    Thanks somebody for the log files. They show me that the Calculated Multiplier method that was designed for the Core i7, has a few issues on Core 2 mobile chips that support IDA.

    Basically you compare two internal timers and see what ratio they are operating at and then multiply that ratio by the default multiplier for that CPU. On my E8400, at full load, these timers will be running at the exact same speed so the ratio is 1:1. You multiply that by the default 9.0X multiplier for this chip and you get 9.0. At idle the timers will operate at a ratio of 0.666:1 so you multiply that by 9.0 and you get the correct 6.0.

    This method works on an IDA chip but the default multiplier on these chips can change so it looks like sometimes my program gets lucky and uses the right default multiplier in its calculation and sometimes not. During your testing you can see where it is using 9.0 as the default when it should be using 8.5. The ratio (9.0/8.5) keeps showing up in your log file.

    I'll try to change my code slightly and put a tiny delay in just before I read the default multiplier. At idle this might help me get the correct results. I'll come up with a fresh version to test later tonight.

    On most Core 2 CPUs and on Core i7/i5 CPUs, the default multiplier is a fixed value and never changes so I don't have to worry about this issue.

    pantherx12: Trying to get RealTemp to start properly when you are using a limited account can be problematic. Needing Admin rights to read the temperature sensors does cause some issues. RealTemp doesn't support AMD CPUs so you don't have to test on that one. What operating system are you running so I can try to do some testing?
     
    Last edited: Oct 3, 2009
  22. pantherx12

    pantherx12 New Member

    Joined:
    Jan 2, 2009
    Messages:
    9,714 (4.16/day)
    Thanks Received:
    1,699
    Location:
    ENGLAND-LAND-LAND
    I have full admin rights, OS is windows seven build 7600.
     
  23. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    996 (0.39/day)
    Thanks Received:
    462
    i7 Turbo 6.93

    http://www.fileden.com/files/2008/3/3/1794507/Turbo.zip

    somebody: What your log file seems to show is that the value in MSR 0x198 bits[46..40] is not a constant value when IDA is enabled. The Current Maximum FID / Multiplier value seems to constantly cycle back and forth between 8.5 and 9.0 on your P8400 based on load. If you are using something like my MSR Tool, it might not be able to show this as each time you try to read it, the maximum multi will jump up to 9.0 and report that.

    With i7 Turbo 6.93, I added a 1ms delay just before that value gets read which should help it report and use the lower 8.5 value from that MSR when the CPU is idle. When your log file was showing a row of 3.177 for the Calculated Multiplier, that's a pretty good sign that it was probably using 9.0 in its calculation instead of the correct 8.5. (9.0/8.5) x 3.0 = 3.176

    Can you post another log file at idle to see if this is improved any? The bottom line is that this method of calculating the multiplier was not designed for Core 2 CPUs that support IDA. I have a feeling that version 6.93 is about as good as it's going to get. I need to have a closer look at the last log files you sent me to see if I notice anything else.

    pantherx12: Did you follow this tutorial exactly?

    http://www.xtremesystems.org/forums/showpost.php?p=3970161&postcount=3657

    In Windows 7 x64 that method works 100% for me. What type of error message do you get or what happens when you use this method?

    I haven't used Windows 7 recently but I'm going to go give it a try again and see if anything has changed recently.

    Edit: After you boot up, open up the Task Manager and see if RealTemp is running. I know there is a RealTemp bug where the program can get located on the screen at a co-ordinate where you can't possibly see it. That's on the things to fix list.
     
    Last edited: Oct 4, 2009
  24. somebody

    somebody New Member

    Joined:
    Sep 28, 2009
    Messages:
    127 (0.06/day)
    Thanks Received:
    27
    I'll try 6.93 out tomorrow but first I tried using MSR 0x30A/0x30B*HFM and it seems to work flawlessly. HFM on the P8400 is 8.5x. What if you went back to how you originally did the calculation by reading 0x198 just once at the start but make sure IDA is set to off in 0x1A0 so that there isn't a possibility to read the IDA multi instead. If IDA is already off then nothing to do but if it isn't you would only need to toggle it once for a few nanoseconds at the start of the program while you read the HFM. Just a thought.

    pantherx12 if you enter taskschd.msc in the 'Start' search box and select your task in the Task Scheduler, there will be a heading called 'Last Run Result' which should give a clue as to why it didn't run.
     
  25. unclewebb

    unclewebb RealTemp Author

    Joined:
    Jun 1, 2008
    Messages:
    996 (0.39/day)
    Thanks Received:
    462
    I'll wait to see your testing with 6.93 tomorrow. Can you also try a brief test at full load with and without IDA enabled to make sure it is still getting the full multi correct.

    From your testing so far, it seems that the ratio of the two timers never exceeds 1.0 on your IDA supported CPU. The way a Core i7-920 works is that this ratio when turbo is enabled works out to 1.05:1 so you multiply that by the default multiplier of 20.0 and you get the turbo ratio of 21.0 or if you only have one core enabled in the bios this ratio will go up to 1.10:1 so the final multiplier is 22.0 (20.0 x 1.10)

    If this ratio does not exceed 1.0 on your P8400 then I need to multiply that by 9.0 when IDA is enabled and by 8.5 when IDA is not enabled.

    Your results from 6.93 should make this clearer. I might have to write a small utility that shows just this ratio so we can see what's really going on with IDA enabled or disabled.

    If this ratio can go above 1.00 like I was originally assuming then your idea to momentarily turn off IDA so I can read the default 8.5 multiplier should work perfectly.

    pantherx12: On Win7 x64 I just tried both methods of starting RealTemp and they both seem to work. The Startup folder or the Task Scheduler works for me when using an account with Admin privileges. There was a bug when I tried to use both methods at the same time but either method individually seemed to work. Once I get the above sorted out then I'll be moving that code back into RealTemp and I'll be working on a few minor RealTemp bugs this week. Maybe I'll find a solution for your problem but I usually have a hard time fixing a problem that I can't recreate.

    Edit: Here's a simple utility that shows you the ratio of the two internal high performance timers, ( MSR 0x30A / MSR 0x30B )

    http://www.fileden.com/files/2008/3/3/1794507/RatioCalculator.zip

    On my E8400 at idle it shows 0.667 which makes sense, ( 6.0 / 9.0 )

    [​IMG]

    At full load this is very steady at 1.000 or ( 9.0 / 9.0 )

    [​IMG]

    I guess the big question now is what does this test show on your P8400 with IDA enabled and disabled at full load? I should have written this originally when you first showed me this issue. It would have saved us both some time if I did. With IDA enabled, this ratio is either going to be 1.000 or 1.059 (9.0/8.5) when running a single thread of Super PI.
     
    Last edited: Oct 5, 2009

Currently Active Users Viewing This Thread: 2 (0 members and 2 guests)

Share This Page