Testing version 5.70

[fred]

Add: Option to adjust the core temperature at the source. See tthrottle.xml.
Add: Independent GPU temperature control. E.g. 70;75;80;65.
Fixed: The calibration can take a very long time on I5 CPU's.

[archae86]

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.

[fred]

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>

Look here: http://www.efmer.eu/forum_tt/index.php?topic=5.msg5#msg5

As far as i know a 4 core CPU with hyperthread, has 4 sensors, one in every core.
There should be only 4 readings.
The logging should be: This Processor has 8 cores and  4 temperature sensors.

The I5 should also read 4 sensors.
The logging should be: This Processor has 4 cores and  4 temperature sensors.

The offset is decimal, so is should be: 0;10;1;11;2;12;3;13
In the logging you should find a line: <PROCESSOR> core_adjust:

But you can't have 8 cores, if you do, something is wrong.

You can try pressing the "Recalibrate" button in the expert tab.

[archae86]

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.   

[fred]

Now I have applied this:

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

You scared me.
10 is a large correction.