RealTemp 2.70

U

unclewebb

[H]ard|Gawd
Joined
Jun 21, 2006
Messages
1,807
I just released RealTemp last night with an updated GUI and quite a few new features including Min and Max VID, Quad core ordering based on APIC ID, more accurate MHz, a high temp alarm and the ability to save log files in Excel friendly CSV format. Start Minimized seems to be working properly in Vista now if you use the Task Scheduler.

It's nice and stable so far during the first 14 hours of testing.

rt270kq5.png


Head here to read more about the new features and to download it. Any comments would be appreciated.

CPU usage during the first 9 hours of testing last night vs the competition was excellent.
Both programs were opened once and then minimized to the SystemTray during this test.

corerealtemphx3.png
 
Nice. I like the new GUI. No problems running on Vista 64 business.

The folder inside the zip I downloaded was named RealTemp_2.60 though.
 
Cool. Downloaded and using now. Is there an option to have realtemp start on windows bootup like coretemp?
 
magnuspah said:
Cool. Downloaded and using now. Is there an option to have realtemp start on windows bootup like coretemp?
Click to expand...

Make a shortcut in your 'Startup' folder and bammo, it will run on bootup.
 
Blue Falcon said:
Make a shortcut in your 'Startup' folder and bammo, it will run on bootup.
Click to expand...

When using Vista I've heard that using the Task Scheduler works best. That allows you to give RealTemp the proper permissions if you are running UAC.

The All Programs -> Startup folder works with Windows XP.

mjh8227: I've passed your info on to W1zzard at TechPowerUp. I checked the files and they are all version 2.70. Just that one folder still says 2.60. :(
 
mjh8227 said:
Nice. I like the new GUI. No problems running on Vista 64 business.

The folder inside the zip I downloaded was named RealTemp_2.60 though.
Click to expand...

I noticed this too. The folder itself was probably named wrong.

Anyways, thanks for the update and link!!
 
Thanks unclewebb for yet another seamless, functional and feature enhanced update.

I run 2 systems (Q6600 w/multi GPUs and E4300 single GPU) pretty much 7x24 crunching Folding@Home so both systems are pretty much fully soaked. I've never had a resource issue with RealTemp and have come to rely on it for no bullshit temps and its' light weight.

Couple of comments: I really like the new CSV logging and temp alarm feature. The fonts in the systray (running XP32) look the same but the display/fonts in the app window seem to be different and are nice and easy to read on these old eyes... I like having the uptime in the app window as well since RealTemp starts and stops with my system.

I do have a feature request though. For the way I use my system it would be awesome to have the date log with the time. Not sure how hard this would be to implement, but it would be very useful as my logs get kinda large running days/weeks on end w/o a reboot. Having the datestamp for max temp only in the app window would also be pretty useful but again not sure how hard this would be to implement.
I'd be more than happy to beta test those features for you if you decide they're doable and worthwhile. Feel free to PM me any time. I'm usually on the forums everyday for a while.

Other than that one (or two depending on your reference point ;)) feature request, I can't think of a thing to make RealTemp better. But I'm sure you will...

Thanks again for a true enthusiasts utility!


 
nomad8u: You're welcome. As a long time overclocker, I appreciate a solid utility as much as anyone. I'd use and recommend RT to others even if I wasn't the guy that wrote it. RT is a combination of a lot of good ideas from users so I'm always open to new ones.

Adding the date to the log file is a good idea and is simple to do. I'll get that done and send you a link to where you can download a beta version in a day or two.

I'm doing some stability testing at the moment so I can't recompile RT until that's done or I get bored. 32+ hours and it's still running fine.

I've also thought about adding a date stamp to the Min and Max numbers. I'm not yet sure about what method I'll use but I'm sure I'll come up with something. :)

One young user complained about the biggy temp numbers. I told him he'd appreciate this feature when he's in his 40's or beyond. I think I copied the TAT font size so people can blame Intel if they don't like it. Now when users post screen shots that have been shrunk in half, I'll still be able to see the temps.

Any thumbs up for the new Mini-Mode that you get when you double left click on the GUI? I like that feature so you can hide it in the corner of your screen. I know some user somewhere is going to have a wtf moment when RealTemp jumps into Mini-Mode and they have no idea how they did it.

Task Manager does the same sort of thing when you double click on it so I'm hoping that people don't get too confused although I did read about one user who ended up reformatting his hard drive when Task Manager did this. :D
 
Hey, another thank you for an awesome piece of software. It is very much appreciated that people out there are nice enough to work on freeware like this!


BTW Did W1zzard make this? He used to be a buddy of mine from back in the day... way back lol. He bought some watercooling stuff from me.
 
You're welcome. W1zzard didn't write RealTemp but he did give me some code to get the System Tray temps working. I appreciate that! I've always enjoyed using a wide range of great freeware programs so I'm happy to give something back to the community. :)

W1zzard was also nice enough to offer to host it on TechPowerUp and provide me with some web space there as well. No complaints and it's reaching a wider audience now compared to when I used to host it myself.
 
unclewebb said:
Adding the date to the log file is a good idea and is simple to do. I'll get that done and send you a link to where you can download a beta version in a day or two.
Click to expand...
Nice.. I was meaning to hit you up with that request for awhile now but with my short attention span... ;) No rush. I've waited this long to mention it I'm sure my quad won't melt before then. Looking forward to testing it out. Thanks.

I'm doing some stability testing at the moment so I can't recompile RT until that's done or I get bored. 32+ hours and it's still running fine.
Click to expand...

17+ hours here on a fully soaked G0 Quad and as you can see RT is light and easy on the resources. a whopping 26sec of processor time and 1.5k of ram. Sweet!





I've also thought about adding a date stamp to the Min and Max numbers. I'm not yet sure about what method I'll use but I'm sure I'll come up with something. :)
Click to expand...
That'd be great. I don't think Min is that important (at least from my perspective since I'n not running LN2 ;)) but Max would be appreciated.

One young user complained about the biggy temp numbers. I told him he'd appreciate this feature when he's in his 40's or beyond. I think I copied the TAT font size so people can blame Intel if they don't like it. Now when users post screen shots that have been shrunk in half, I'll still be able to see the temps.
Click to expand...

That's right.. he'll appreciate it when the eyes get a tad weaker.

Any thumbs up for the new Mini-Mode that you get when you double left click on the GUI? I like that feature so you can hide it in the corner of your screen. I know some user somewhere is going to have a wtf moment when RealTemp jumps into Mini-Mode and they have no idea how they did it.

Task Manager does the same sort of thing when you double click on it so I'm hoping that people don't get too confused although I did read about one user who ended up reformatting his hard drive when Task Manager did this. :D
Click to expand...

Completely forgot to mention it but yeah, it's awesome. small and out of the way and still have quick access to the "cycle" button in case I need to check speed or FSB quickly. Although honestly, it just sits quietly in my system tray where I can take a quick glance at it now and then. I will probably make use of the alarm though. I did not know that Task Mangler did that. I primarily use Process Explorer and like it much better. But it wasn't a wasted day now, as learned something new.


 
I'd also like to thank you for making this wonderful program. I absolutely love being able to minimize it and display on my taskbar the highest core temp. :D
 
I cant get this to work on 32bit vista. Says I need to be on an admin account and the driver wont load. I am on an administrative account though. Any ideas?

Edit: got it working. :)
 
If you run Test Sensors and do some XS Benching it will chew up some CPU time but when sitting in the System Tray doing nothing, it's very efficient. Thanks for all the smiling faces and thumbs up. Positive feedback keeps me motivated to make it an even better program. Any more suggestions to add to the things to do list?
 
unclewebb said:
Any more suggestions to add to the things to do list?
Click to expand...

I guess if we're wishing, GPU and HD temps thrown in would be nice. If I only had to pick 1 of these it'd be GPU.

I use GPU-Z for temp monitoring, but only bring it up occasionally just to check it. For Folding with the GPU's they run full-tilt 7x24 as well as the CPU so it'd be nice to have that in one easy to monitor location.

Just noticed what may be an issue. I'm using csv logging and have it set to 180. for some reason it stopped logging @ 10:15 this morning. This is around the time I had opened the RT window to check uptime hours. I checked the settings and it's still set for logging but isn't.

Uptime was @ 33+ hours with this being the only issue so far. I'm going to shut RT down, rename the log and restart RT and see if I can reproduce the problem.

A cut from the end of the log:
Code: 
9:00:00	47	46	47	43
9:03:00	45	46	45	43
9:06:00	46	46	45	42
9:09:00	47	46	46	42
9:12:00	45	46	44	42
9:15:00	47	46	46	43
9:18:00	45	46	44	42
9:21:00	46	46	45	42
9:24:00	46	46	45	43
9:27:00	47	46	44	43
9:30:00	46	46	44	42
9:33:00	46	46	45	42
9:36:00	47	46	46	43
9:39:00	46	46	44	42
9:42:00	45	46	45	43
9:45:00	46	46	45	42
9:48:00	45	46	45	43
9:51:00	47	46	46	43
9:54:00	42	44	41	41
9:57:00	42	44	40	40        
10:00:00	42	44	40	40
10:03:00	42	44	40	40
10:06:00	42	44	40	40
10:09:00	49	46	47	43
10:12:00	45	46	45	41
10:15:00	46	46	45	43


 
nomad8u said:
Just noticed what may be an issue. I'm using csv logging and have it set to 180. for some reason it stopped logging @ 10:15 this morning. This is around the time I had opened the RT window to check uptime hours. I checked the settings and it's still set for logging but isn't.

Uptime was @ 33+ hours with this being the only issue so far. I'm going to shut RT down, rename the log and restart RT and see if I can reproduce the problem.
Click to expand...

Dang... my bad. forget what I said, I'm an idiot. I had opened the CSV to check if it was logging OK and I guess RT couldn't update it until after I closed the log. Even though I closed and opened it several times at a couple of minutes interval each. It updated when I closed RT.

It's a shame because I was at +33 hours uptime on it. Oh well... sorry for the false alarm. :)
 
Downloaded it to try it out over CoreTemp. One thing I noticed on my B3 Q6600 is the Tjmax is set at 85 initially, should be 100 (temps are shown 15C lower). That might be a problem for new users trying out the program, anyway to get it to 100 automatically or does it always start out at 85 and you set it according to your CPU?
 
nomad8u: I was just about to tell you what's likely going on when you sort of figured it out by yourself.

I disagree with tiny amounts of data being constantly written to the hard drive so RealTemp writes this data to memory first. When logging at a 1 second interval having a program access your hard drive every second is over kill.

Previous versions of RealTemp used to only write to the hard drive once per hour. That was a bit extreme and caused a problem for one user when his computer would do a BSOD, he'd lose his temperature data that was cached in memory. My compromise now is a write to hard drive every 5 minutes.

In order to keep both users happy, I added an option to 2.70 that can be entered into the INI file to adjust how often you want RealTemp writing to your hard drive. By default it is:

HDWrite=300

That's 300 seconds which is once every 5 minutes. If you use HDWrite=1 then every time new data is generated, it will be written to your hard drive log file based on your logging interval that is set within the Settings window.

Maximum is 86400 which would mean RealTemp would only write the log file to your HD once per day at midnight. That extreme might be handy if your computer had stability issues and you were trying to get a nice long Prime run and didn't want any third party software screwing up a perfect Prime stability screen shot of your not quite perfectly stable, overclocked to the moon computer. :D

With RealTemp, you get to be the boss. When testing with CoreTemp overnight at a 1 second logging interval I opened it up the next morning and noticed 30000+ hard drive accesses since the night before. I'm like having full control of that with RealTemp.
 
Mr. K6 said:
Downloaded it to try it out over CoreTemp. One thing I noticed on my B3 Q6600 is the Tjmax is set at 85 initially, should be 100 (temps are shown 15C lower).
Click to expand...

Why should it be set to 100C for your B3 Quad? Do you have some documentation from Intel to back that up or are you assuming that because all of the other software assumes that number.

RealTemp is based on real measurements. Read the docs and try doing the low MHz, low volt calibration and you might come to realize that TjMax=100C for your Quad is a myth.

A B3 Quad consists of two B2 Dual Core processors which both had TjMax=85C. Why do you think the B3 is different?
 
I see that by default, the TJmax on my Q6600 G0 is 95C in your application while I know a lot of the others have it set to 100C. I am not trying to offend you or anything, but what made you set the default to 95C instead of 100C? Which one is the right one?
 
TjMax is based on testing with an IR thermometer pointed at the bare core. The difference between an IHS measured temperature and the true core temperature is between 0C and 1C at idle according to Intel's testing so I think my testing is valid. My present CPU which I used during testing is a Q6600 - G0.

The competition is basing their TjMax numbers on Intel documentation for the mobile processors or on the Intel TAT program which is also a testing program designed for the mobile processors. I chose to disagree with that and have based RealTemp on real world testing.

Start by reading the documentation and you will learn why I think some of the TjMax values that have been chosen by the competition are dead wrong. Too much has been assumed for too long with no testing to back it up.

Here's my favorite test of an E8400 which explains my methods:
http://www.xtremesystems.org/forums/showpost.php?p=2883315&postcount=573

Another source of information is CompuTronix over at Tom's Hardware who has been studying the issues for two years now. He recommends RealTemp over CoreTemp for a reason.

Comp also explains his thoughts about the B3 here:
http://www.tomshardware.com/forum/252165-28-measure-cpus-temp
 
unclewebb said:
TjMax is based on testing with an IR thermometer pointed at the bare core. The difference between an IHS measured temperature and the true core temperature is between 0C and 1C at idle according to Intel's testing so I think my testing is valid. My present CPU which I used during testing is a Q6600 - G0.

The competition is basing their TjMax numbers on Intel documentation for the mobile processors or on the Intel TAT program which is also a testing program designed for the mobile processors. I chose to disagree with that and have based RealTemp on real world testing.

Start by reading the documentation and you will learn why I think some of the TjMax values that have been chosen by the competition are dead wrong. Too much has been assumed for too long with no testing to back it up.

Here's my favorite test of an E8400 which explains my methods:
http://www.xtremesystems.org/forums/showpost.php?p=2883315&postcount=573

Another source of information is CompuTronix over at Tom's Hardware who has been studying the issues for two years now. He recommends RealTemp over CoreTemp for a reason.
Click to expand...
I did not realize this program was based off your own testing. I am not a computer engineer or even a technician, however there seems to be a fundamental flaw in your testing process. Your real world measurements are based on the thermal reading off the top of the CPU, as shown in the XS post. However, you are using this reading as a basis for calibration of your Tjmax value in the program. It would seem that what you're actually measuring is the Tcase, which is a substantially different value and has a much lower threshold (to use my example processor Q6600 B3 CPU, I think its 62C). I doubt you can mix the two values. Unless you had a bare CPU core (which would be close to impossible to measure without placing a probe in between CPU and heatsink), the value measured by any thermometer by placing it on the IHS is going to be a good deal lower because the IHS acts as a sink for the die. Please correct me if I am viewing this incorrectly.
 
This has all been discussed and tested over at the XtremeSystems forum which is the main forum for RealTemp. When I get a chance I will hunt through it and find the independent testing that disagrees with what you believe is true.

One user ran two IHS heat spreaders on the same CPU and compared it to using only one IHS and the "substantial difference" in temperatures simply didn't exist.
 
unclewebb said:
This has all been discussed and tested over at the XtremeSystems forum which is the main forum for RealTemp. When I get a chance I will hunt through it and find the independent testing that disagrees with what you believe is true.

One user ran two IHS heat spreaders on the same CPU and compared it to using only one IHS and the "substantial difference" in temperatures simply didn't exist.
Click to expand...
Why would you run two IHS? I'm talking about the difference between having an IHS and no IHS. The latter would produce the only accurate die temperature. The only other way I could see of doing it would be to do an accurate thermal profile of the heat dissipation properties of the IHS and surrounding socket, but like I said I'm no engineer.
 
Thanks again unclewebb for this fine program, it's amazingly efficient and the options available to configure that are available now are great!


 
Here's the testing that rge did and posted at XtremeSystems. His goal was to prove that at idle, there isn't a huge temperature difference between the top of the IHS and the temperature of the core. Here was his conclusion after testing his E8400.

"Realtemp 95 tjmax is clearly correct. No way, no how is tjmax 105 because no way no how does a 10C gradient exist through tim and IHS, in fact it is clearly less than 1-2C."

http://www.xtremesystems.org/forums/showpost.php?p=3085792&postcount=1525

The Intel engineers discovered this when comparing core temperature to case temperature.

"It also can be noted that some workloads display high temperature gradients while other have no offset."

http://arxiv.org/ftp/arxiv/papers/0709/0709.1861.pdf

No offset means there was no difference in temperature between core temperature and case temperature when running some applications. When a processor is idle, large gradients between these two values do not exist.

With the shrink to 45nm, the temperature gradients continue to decrease even at full load. One interesting test I did with my E8400 was to run one instance of Prime95 small FFTs on one core and then I ran absolutely nothing on the other core. Half way through the test I swapped the load to core1 and let core0 run idle. The average difference was approximately 1C. The individual cores on a Dual Core are so close together now that running one of them at full load will heat up a completely idle core to almost the exact same temperature. Use Task Manager and Set Affinity... to move Prime95 while it is running from one core to the other. The large gradients that existed in CPUs from a couple of generations ago don't exist anymore and certainly not at idle where I did my testing.

Try my test with your B3. Lock your CPU to 266 MHz x 6.0 in the bios and drop the core voltage to about 1.10 volts. Boot up and set TjMax=85C. Turn your CPU fan up to max and get your idle temperature as cool as possible. If your reported temps are a degree or two below your room temperature, that is not a sign that TjMax is wrong. It's a sign that these sensors are not 100% accurate at idle. Intel admitted to this and there is a link in my documentation to what they said in an AnandTech interview. The B2 Dual Cores that I have tested have sensors that tend to report at least 5C too low at idle.

If you're still not convinced, use the adjustable TjMax feature in RealTemp and you can set it however you like. Before you do that, I hope you at least do your own testing. I'm very interested in seeing some numbers from your B3. If my choice of TjMax is wrong by 15C then your results at idle will clearly show that.
 
unclewebb said:
I disagree with tiny amounts of data being constantly written to the hard drive so RealTemp writes this data to memory first. When logging at a 1 second interval having a program access your hard drive every second is over kill.

Previous versions of RealTemp used to only write to the hard drive once per hour. That was a bit extreme and caused a problem for one user when his computer would do a BSOD, he'd lose his temperature data that was cached in memory. My compromise now is a write to hard drive every 5 minutes.

In order to keep both users happy, I added an option to 2.70 that can be entered into the INI file to adjust how often you want RealTemp writing to your hard drive. By default it is:

HDWrite=300

That's 300 seconds which is once every 5 minutes. If you use HDWrite=1 then every time new data is generated, it will be written to your hard drive log file based on your logging interval that is set within the Settings window.

Maximum is 86400 which would mean RealTemp would only write the log file to your HD once per day at midnight. That extreme might be handy if your computer had stability issues and you were trying to get a nice long Prime run and didn't want any third party software screwing up a perfect Prime stability screen shot of your not quite perfectly stable, overclocked to the moon computer. :D

With RealTemp, you get to be the boss. When testing with CoreTemp overnight at a 1 second logging interval I opened it up the next morning and noticed 30000+ hard drive accesses since the night before. I'm like having full control of that with RealTemp.
Click to expand...

Beautiful. I like the 5 minute write intervals and am willing to risk the data loss for that. It seems like a nice balance between functionality and performance. Exactly why I run RealTemp in the first place... The option to customize it is icing on the cake,

Thanks for the in-depth description and reasoning behind it. Another reason I run RealTemp. I'll be adding this to my RT notes file. I got a little behind keeping up with the thread at XS so it was probably discussed there and I missed it... Sorry.


 
unclewebb said:
Here's the testing that rge did and posted at XtremeSystems. His goal was to prove that at idle, there isn't a huge temperature difference between the top of the IHS and the temperature of the core. Here was his conclusion after testing his E8400.

"Realtemp 95 tjmax is clearly correct. No way, no how is tjmax 105 because no way no how does a 10C gradient exist through tim and IHS, in fact it is clearly less than 1-2C."

http://www.xtremesystems.org/forums/showpost.php?p=3085792&postcount=1525

The Intel engineers discovered this when comparing core temperature to case temperature.

"It also can be noted that some workloads display high temperature gradients while other have no offset."

http://arxiv.org/ftp/arxiv/papers/0709/0709.1861.pdf

No offset means there was no difference in temperature between core temperature and case temperature when running some applications. When a processor is idle, large gradients between these two values do not exist.

With the shrink to 45nm, the temperature gradients continue to decrease even at full load. One interesting test I did with my E8400 was to run one instance of Prime95 small FFTs on one core and then I ran absolutely nothing on the other core. Half way through the test I swapped the load to core1 and let core0 run idle. The average difference was approximately 1C. The individual cores on a Dual Core are so close together now that running one of them at full load will heat up a completely idle core to almost the exact same temperature. Use Task Manager and Set Affinity... to move Prime95 while it is running from one core to the other. The large gradients that existed in CPUs from a couple of generations ago don't exist anymore and certainly not at idle where I did my testing.

Try my test with your B3. Lock your CPU to 266 MHz x 6.0 in the bios and drop the core voltage to about 1.10 volts. Boot up and set TjMax=85C. Turn your CPU fan up to max and get your idle temperature as cool as possible. If your reported temps are a degree or two below your room temperature, that is not a sign that TjMax is wrong. It's a sign that these sensors are not 100% accurate at idle. Intel admitted to this and there is a link in my documentation to what they said in an AnandTech interview. The B2 Dual Cores that I have tested have sensors that tend to report at least 5C too low at idle.

If you're still not convinced, use the adjustable TjMax feature in RealTemp and you can set it however you like. Before you do that, I hope you at least do your own testing. I'm very interested in seeing some numbers from your B3. If my choice of TjMax is wrong by 15C then your results at idle will clearly show that.
Click to expand...
Wow, excellent explanation, thank you. I see what you're saying about the discrepancy at idle and have read through that documentation. My concern is more about load temperatures, as I run F@H 24/7. It seems that there isn't as much of a discrepancy there, but the situation then seems to present itself as an either/or - if I offset my Tjmax to reflect accurate idle temperatures then my load temps are not accurate and vice versa due to the non linear nature of the increasing temp curve. Let me read through all the materials you provided, thanks again.
 
nomad8u said:
Thanks for the in-depth description and reasoning behind it. Another reason I run RealTemp. I'll be adding this to my RT notes file. I got a little behind keeping up with the thread at XS so it was probably discussed there and I missed it...
Click to expand...

No problem. With about 80 pages of stuff in the RT forum over at XS, it's easy to miss a page or three! I put most of the new RealTemp features in the updated documentation. Scroll about half way down to the RealTemp.ini section and it explains the HDWrite option. No need to bookmark this thread!

Mr. K6: Bumping up TjMax can cover up the problems these sensors have at idle but it doesn't cure things. If you change TjMax to the wrong value, your load temperatures will no longer be accurate. That's why the RealTemp calibration has no effect after about 60C. The 65nm sensors work very well above this temperature.

The Intel documented thermal shutdown temperature is 125C for the mobile Core 2 Duo CPUs and I believe the desktop Core processors are the same. One user sent me a screen shot of his Q6600 - G0 at 123C. He tried a handful of times to get a higher screen shot but each time his computer would shut down.These sensors have to be accurate at 95C which is the thermal throttling point for most of these CPUs and also at the 125C shutdown temperature so I think the most accurate range for them is probably 95C +/- 30C which is about 65C to 125C. That's what I'm seeing during testing. Some of the newer 45nm sensors might have a slightly narrower range where they are basically 100% accurate.

The theory behind RealTemp is to use the correct TjMax so your load temps are accurate and then provide users with a way to correct for inaccurate idle temperatures due to the limitations of these sensors. I can't look at a processor or a model number and know what the sensors are going to do at idle so the best solution I thought would be to let users calibrate RealTemp to their CPU for better accuracy at idle. The end results are excellent without having to invest a nickle in something fancy like the IR thermometer I purchased.

Sorry to load you down with test results and documentation but I just wanted everyone to know that my choice of TjMax wasn't just a number picked randomly off of the top of my head and I didn't see how following the herd was going to help out either. There's just no way that a linear model can cover the data I've collected. It was really funny that within 3 days of RealTemp's initial release that some one from Intel finally publicly admitted that their sensors are not linear from idle to TjMax. Nice coincidence! CoreTemp, Everest, Speed Fan, HW Monitor, etc. all continue to assume that these sensors have a linear temperature response curve.
 
Looking good unc! Would have been close to 140hr by now if I hadn't of goofed it. Great job! I'd have given you a shot of 100 even but don't think I'm going to be awake in 12 minutes.. ;)



RealTemp, Helping to Fold for a cure!


 
Very nice...I really like the new GUI...can't wait to try out this newer version with my E8400 once my Shuttle is running.
 
cornelious0_0 said:
Very nice...I really like the new GUI..
Click to expand...

I'm glad I didn't listen to GigaByte who didn't seem to like the big, easy to read temp fonts. I'm thinking about doing a second version of RealTemp for users that prefer more of a CoreTemp style layout.

Does anyone use the new RealTemp anchor feature? A double right mouse click will move RT to an anchor position on screen. Default is the top left corner and you can set your own anchor position by holding down the Shift key on the keyboard and then doing a double right mouse click. I thought this was handy but most people don't bother reading the docs so probably don't know about this feature yet. Spread the word!
 
unclewebb said:
When using Vista I've heard that using the Task Scheduler works best. That allows you to give RealTemp the proper permissions if you are running UAC.

The All Programs -> Startup folder works with Windows XP.

mjh8227: I've passed your info on to W1zzard at TechPowerUp. I checked the files and they are all version 2.70. Just that one folder still says 2.60. :(
Click to expand...
Yeah found this link on google, I'm going to try it out.
 
Thanks silent hero. I'll have to add that link to the RealTemp documentation.

Sorry guys but the [H]ard gods have turned off my ability to post url links. I thought posting additional information would help users understand these temps sensors better. Contact me by the email address within the About... of RealTemp if you ever need more info. I guess sharing free software with the [H]ard crowd is considered to be a bad thing. :confused:
 
Very strange...on another note I can't even do anything with RealTemp at the moment, it doesn't support the older s478 P4 in this system I'm working on and have sole access to so I'll have to wait until my Shuttle is up and running again to critique the new GUI for myself.
 
for my e8400 real temp has tjmax at 95, coretemp tjmax is at 105 , speedfan is at 100...so i look at the temps and they read 32,31 for real temp...37,36 for speedfan...42,41 for coretemp...idle... so i like realtemp for reading temps...
 
asiandunn30 said:
for my e8400 real temp has tjmax at 95, coretemp tjmax is at 105 , speedfan is at 100...so i look at the temps and they read 32,31 for real temp...37,36 for speedfan...42,41 for coretemp...idle... so i like realtemp for reading temps...
Click to expand...

It's not even a matter of which one you like, as far as I know the TJMax for 45nm C2D's is 95c...but again, Intel hasn't said for sure so it's just the best guess we've got.
 
You must log in or register to reply here.
Back
Top