Messages

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?

Thanks Fred,

I responded at greater length by email.  Here I'll say that I was able to create a 3-minute startup delay on my Windows 7 system using Start|All Programs|Accessories|System Tools|Task Scheduler.  I used the "create Tasks" function (not basic task), using the "triggers" tab to select Startup, and specifying a delay in the advanced section on the same page.

This seems to work as to initiating a working copy of TThrottle64 without the catastrophic problems this particular system exhibited when I used the usual non-delayed form--but the system tray icon does not appear.  When I went to the Customize... section in the show hidden icons function for the system tray, I did find what appeared to be a TThrottle entry--specified to show icon and notifications. 

Shutting down this Task Scheduler started copy of TThrottle using Process Explorer, then starting a fresh copy with a Start|Run command to the same executable, I do get the icon--so it appears there is some option I should have employed in using Task Scheduler that eludes me.

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.

And where are the instructions to be found?

My error was a persistent misconstruing of the meaning of the parameters based on the example--I imagined they were ordered pairs of CoreNumber; CoreOffset

So in fact I was always applying an offset of 0 to core 0, and an offset of 1 to core 2, and the offset I imagined I was specifying for core 0 of course was applied to core 1, and so forth.

Now I have applied this:

      <Core_adjust>8;4;1;10</Core_adjust>

and for my system, with four Einstein Gravity Wave CPU jobs operating on four separate physical cores, the reported temperatures are matched quite well.

I can't explain either how I first formed my mistaken impression of the construction of this parameter setting, nor how I persisted in the error for a couple of hours of debugging--but it is over now, and my impression is that 5.70 is working as desired for this function on my main system.  I'll try it out later today on the Sandy Bridge 4-core non-HT system and report again.   

I have installed TThrottle 5.70 to one host.  After careful testing, including trial offsets individual on four cores, then eight, it appears to me that I can only alter the offset for cores 1 and 3, and that those offsets are provided by the parameters I post for cores 0 and 2.  While rather confusing, this allows me to match three of the four cores, which probably means I can improve consistency already, but if I am observing accurately, this must not be the intended behavior.

System details
Windows 7 Professional 64-bit, with current updates
CPU is an Intel E5620 (nominally a Westmere, but architecturally very close to a Nehalem)--with four physical cores running hyperthreaded, so eight virtual CPUs.

Using forced CPU affinity and monitoring an independent temperature report from Speedfan, I was able to establish that for temperature reporting Tthrottle reports Core 0,1,2,3 corresponding to Speedfan temperature reporting for Cores 0,2,4,6.

Using the formulation in TThrottle xml like:

<PROCESSOR>
  <Core_adjust>0;a;1;b;2;c;3;d</Core_adjust>
</PROCESSOR>

I observed that the value supplied as "a" was added to the reported temperature for core 1 by TThrottle, and the value supplied as "b" was added to the temperature for core 3.  Signed integers appeared to work as expected (i.e. both positive and negative adjustments worked).  Values supplied for "c" and "d" had no observable effect.  The reported values for cores 0 and 2 were unchanged by values tried in this file.

As for some purposes an HT part with four physical cores is considered to have eight cores, and numbering oddities were already apparent, I tried an eight-core version of this line instead:

<PROCESSOR>
  <Core_adjust>0;a;1;b;2;c;3;d;4;e;5;f;6;g;7;h</Core_adjust>
</PROCESSOR>

In this case, the response to parameters a and b was the same as before, and none of parameters c through h appeared to have any effect.

I have another Windows 7 64-bit system running a Sandy Bridge i5-2500K processor with four physical cores and no hyperthreading.  If running a similar test on it would add useful debugging information I'm happy to do so.  For that matter, I also have an 6600 Windows XP Pro 32-bit (ancient Conroe dual-core) and a Q9550 XP Pro (Pennryn generation quad-core) available for testing.

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 will add this to the tthrottle.xml file

<PROCESSOR>
  <Core_adjust>1;-1;0;-2</Core_adjust>
</PROCESSOR>

Wonderful.  As not all applications which reference Intel Cores number them the same, I'd assume users can figure what will work for them in yours by checking the temperatures shown in the temperature tab of TThrottle.

By the way, I am a former Intel person, and in the distant past was a microprocessor design person, then reliability, then factory data analysis for yield improvement.  I won't, precisely, claim inside knowledge for my comments on sensor historical purpose and sensor error, but am actually pretty confident in them.

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.

I had what appeared initially to be a freeze of the type previously discussed.  I went to the logging window, but checking the debug box did not cause visible logging.  So I tried to turn on "magic" logging.  Unlike previous versions in previous incidents, neither clicking the the debug box nor typing "magic" (which did stimulate a "full debug" notification) caused the logging box to start making a new line per second.

After perhaps a couple of minutes it appeared to unfreeze.  Just before the start of the incident, I had selected just one of the five hosts, and the first thing I noticed at the unfreeze was that the display abruptly shrank to that the lines for that host.  Then I noticed that the status area had resumed the regular countdown to updates, rather than staying frozen on "updating."  This seems good--perhaps one of the palliative measures unfroze me.

There was some abnormal things in exiting the program, but I'll refrain for description, as my memory is not crisp on just what happened, though two elements I am sure of is that it did not initially terminate when asked to from the task tray popup menu, and that when it finally did terminate I got the Windows abnormal termination--ready to send data to Microsoft popup--which I have not previously seen from BoincTasks.  I failed to try to collect any information from that, however.

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.

As soon as this happens.
Make sure the task view is visible.
Disable TThrottle communication in the setup dialog.
Go to help -> show log.
Click on the log dialog and type in magic  In the bottom of the dialog it should show "full debug" and keep it there for a minute or 2 and copy everything in the log and send it to me.

I did not have an episode for about a day, but did have one this morning.

Sequence of observations:
9:46 a.m., clicked on BoincTasks Task Bar icon, regular BT 0.52 window came up promptly, looked normal, but the status box (third from right at on the bottom row), which usually says "updating very briefly, then a count-down from 5 seconds to next update, instead said "switched, busy" for a while, perhaps 20 seconds.
Then it changed to "updating..." but held that steady past 9:49 (i.e. at least three minutes, with no actual change to the displayed accumulated CPU time, etc.).

I tried to follow your directions, but had difficultly copying and pasting the contents of the log window.  I can describe what was there, however, one line per second, all reading in a steady sequence, so showing just three I now find I can copy having stopped the logging will give the gist:

Code Select Expand

30 April 2010 - 09:52:11 OnTimerDlg ---- m_bThreadBusy: 0, m_bThreadHistoryBusy: 1, m_iTrickleWuTimer: 5, m_iTrickleMessageTimer: 3395, m_iUpdateWuTimer: 3413
30 April 2010 - 09:52:12 OnTimerDlg ---- m_bThreadBusy: 0, m_bThreadHistoryBusy: 1, m_iTrickleWuTimer: 5, m_iTrickleMessageTimer: 3396, m_iUpdateWuTimer: 3414
30 April 2010 - 09:52:13 OnTimerDlg ---- m_bThreadBusy: 0, m_bThreadHistoryBusy: 1, m_iTrickleWuTimer: 5, m_iTrickleMessageTimer: 3397, m_iUpdateWuTimer: 3415
I then tried to kill BT using the "End" command on the popup menu from the tray icon, sometime around 9:53 a.m.  As of 9:59 a.m. it still had not in fact exited.
At 10:00 a.m. I killed it from Process Explorer.

I suspect Corsair's comment about this being associated with hosts which have dropped out of communication, at least temporarily, has truth in it.  But when I relaunched BT 0.52 at 10:02 a.m. it promptly acquired data from all five of the hosts listed in the "all computer" list.  So I am not at all confident that whichever of my hosts it may have had trouble seeing for a while stayed inaccessible to it for the entire episode of 15 minutes, and just happened to resume accessibility within the next minute or two.

tonight had some strange crash, the OS has shown the windows of "BoincTasks has ... and has to close - do you want to send report"

Please read this:
http://www.efmer.eu/forum_tt/index.php?topic=338.0

I have a recurring bad behavior for which I'd like to attempt a useful report.  Roughly once every day or two, it appears that BoincTasks on my host goes to a state in which it is no longer updating.  When it is in this state, right-clicking on the Task Tray icon and selecting "Exit" from the resulting popup menu does no in fact terminate BoincTasks (or at least not in the time I've chose to wait--up to a minute or two, whereas in normal operation it terminates in response to this action much more quickly).

I confess that while I'm responding to a BT 0.52 thread, I have not yet upgraded past 0.51, but I've observed this behavior on all versions I have run so far.

Is there any information I can collect in the undesired state which would make this report useful?  In particular, should I attempt to follow the procedures specified in the link you give above?   (Remember, the ap does not actually "crash" on its own,  I hard kill it using Process Explorer). 

My BT host runs Windows XP Pro SP3 on a Q6600 Core2 Quad CPU.  I'm upgrading to BT 0.52 now, so will soon be able to report if the behavior I'm discussing seems to persist.

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.

v0.49 64-bit version crashed immediately on startup on my Intel Core Duo, Vista SP2 laptop host.  First install was as an update, installing over v0.48 with no reboot (never a problem with earlier versions).  Next I rebooted the machine, same result.  Next I tried a "clean" install, after uninstalling via the Control Panel--same result.  Possibly there's some incompatibility with previously written Registry keys that aren't being removed by the uninstaller?

I've reverted to v0.48, operating normally.  

Possibly similar to my experience.  I was installing to a host which had been running Beta .46.  The machine is a Windows XP Pro SP3 32-bit Core 2 Quad.

On launching BOINCTasks for the very first time, I got an instantaneous "please tell Microsoft about this problem" popup.  Clicking on the "see what data this error report contains" shows an extensive dump, but I could not seem to select it for copy and paste, and the 4k file it proposed to send along with the dump to Microsoft had little in it (though I did save it).

I tried an uninstall from Control Panel, turning off my COMODO firewall, which has interfered with a very few installations, and a new install, but that gave the same result.  Reinstalling version .46 without even a reboot came back up and running.

If I can make this report more useful by providing additional information or running tests I'd be happy to help out.