Topics

I run TThrottle on three systems, monitoring and sometimes controlling a fleet of graphics cards which has varied over the years, such as GTX 1070 and AMD Radeon Radeon RX 570 and Radeon VII.

So far as I can recall, on initial install on new systems, TThrottle has always found a suitable temperature sensor reporting from the GPU, and been able to use it for a while.  But after a time (and presumably after various Windows software updates and Nvidia or AMD drivers updates) a given Tthrottle installation seems to forget how to see temperature on all of my GPUs.

I've used the workaround of starting and referring to a copy of GPU-Z, but I'd be happy if there were a way to get TThrottle to re-do the search for suitable sensors it does at the first startup, as I suspect it would succeed.

Is there a way?  would I need to uninstall TThrottle and delete some registry entries, then reboot and do a new installation?

I've been running TThrottle with pleasure on several hosts for a while.  Some weeks ago, I had severe startup problems on one machine, and by progressive elimination of automatically started programs using selective startup in msconfig, I learned that if I did not allow the automatic startup of TThrottle my main startup problems went away.

Starting TThrottle after everything else is up and running seems to work fine, save that for my 4-core 8 virtual core Xeon E5620 only one core shows, whereas Speedfan and other programs show 4 or eight.

Instead of manually starting TThrottle after boot, I'd like to just do a delayed launch.  Do you have any suggested means to accomplish this cleanly?

When I came here to ask my delayed start question, I had a look around, and happened to spot your advice to fix cases where not all cores are reported in TThrottle using:

HKEY_CURRENT_USER\Software\eFMer\TThrottle64\calibration
value: cores should be 8

Interestingly enough, I found this value on my offending host to be at all f's (hex).  I revised it to 8 but the reporting behavior did not change in my case (still just reports one core in TThrottle).  Is it possible the all f value may have had something to do with my problems when TThrottle is launched during Windows boot?  I've not experimented after the regedit, as the behavior is pretty bad, and each trial somewhat lengthy.

Thanks for any help.

I'm no expert on this, but people I normally trust say that with BOINC version 7 debt is gone, while a not completely different thing called REC is a crucial element in determining how work across multiple projects is managed for both download and running priority.  I don't know how or whether it is published, save that it appears in client_state.xml for each project using the tag <rec>.

As I've found the debt column in BoincTasks interesting, I'd think it useful to handle REC.  I don't know the best way, but the simplest might be to leave the debt display for older BOINC hosts as-is, but display REC in the same column for newer hosts.

However, it has always seemed odd to me that BoincTasks displays debt as a column in the Tasks view, as I think it is a project attribute.  So my real guess of the best thing to do would be to remove the existing debt column from the Task view, and to add a new column to the Projects view, which for hosts running older BOINC would be populated with the debt value, and for current V7 hosts would be populated with the REC value.  Possibly the column header should best indicate both possibilities (perhaps debt/REC).

I wish TThrottle would support user-specified offsets to the reported temperature by core.  This would allow much more consistent throttling for those of us running less than 100% of cores on BOINC.

Background: The on-die temperature sensors used on Intel microprocessors were originally put there to support a fleet-wide reliability objective by reducing the amount of excess-temperature abuse seen in service.  So far as I know, they, and the control systems in which there are embedded, are serving that function adequately, but there are actually rather bad thermometers.  Surprisingly enough, they are often not well-matched from core to core on the same die.  While users often think such mismatches are symptoms of poor application of thermal grease, misaligned heat sinks, and such, offsets are near zero power are not from those causes, and often offsets at high power are not either.

For TThrottle users who run BOINC applications on every available core, all of this is not an issue, as they can just dial in a desired boundary suitable for the highest-reading core, and all else tracks.

But on my GPU-equipped machines, I've decided, as do many others, to run less than a full set of CPU applications (most just leave one idle core--whereas I am running only two CPU tasks on one four-core non-hyperthreaded Sandy Bridge and also on one Nehalem with eight virtual cores).  Given the large temperature offset of the sensors on my cores, this means the real amount of throttling varies just because of which core Windows happens to assign my running BOINC CPU tasks to.  On Windows 7 these assignments seem to be stable over many minutes of time--without the hectic shifting seen under Windows XP.

Speedfan, for a well-known example, supports per-core user-specified temperature offsets in the form of an integer to be added or subtracted for each core from the reported reading.  While this can't handle some of the more obscure errors, including missing codes, slope error, and such, it is good enough for most purposes for most of the CPUs I've owned or heard reports on, and I think would be a nice addition to Throttle.

Let it run for about 5 minutes with the Tasks view visible.

Copy the log file that's in the user folder datenumber.log and mail it to me. (This is a plain text file.)

Sadly, it froze again, so I followed your directions and have mailed you a log.  In case others try this, just two extra tips:
1. At least on my Windows XP Pro system, the log file appeared in Documents and Settings\ (user here) \Application Data\eFMer\BoincTasks\log,
2. I had to actually kill BoincTasks (by hand from Process Explorer) before the Gmail web client would attach the log file--presumably it was locked in some sense.

I was one of the folks for whom BT 0.49 crashed instantly on each launch I tried after installation.  I reverted to BT 0.46 for the last day.

Today I installed BT 0.50 by the same careless method I enjoy using when it works (not rebooting, not shutting AV and Firewall stuff, and not getting out of all applications).

Despite my carelessness, it installed and then started up just fine.  So the crash issue observed on my particular host seems to have been successfully resolved by the fix Fred mentioned in BT 0.50.

Not sure if this belongs on the Beta Testing section, but since it is a possible bug, it seemed not to belong with suggestions.

Anyway, I am running version 0.42.  When I exited it for the first time, on restart it only connected with localhost, but not the four networked hosts to which I had been observing before the exit.  Upon using the Computers|Show|Password column, I noticed that the password I had entered was shown in all lowercase.  When I re-entered the password with correct case, the program reconnected.

Possibly this is a bug.