Testing Version 3.11

[fred]

Fixed: A child process is shown in the list, but not throttled.

[Pepo]

Fixed: A child process is shown in the list, but not throttled.

They seem to be throttled correctly now.

Fred, what about (optionally?) excluding wrappers from throttling? Is there any reason to throttle them too? From what I've seen in the past, they consume merely a couple of seconds throughout their existence, they just act as communicating channels for the client. (Means even less load for TTh while throttling...)

[fred]

They seem to be throttled correctly now.

Fred, what about (optionally?) excluding wrappers from throttling? Is there any reason to throttle them too? From what I've seen in the past, they consume merely a couple of seconds throughout their existence, they just act as communicating channels for the client. (Means even less load for TTh while throttling...)

But checking = more overhead. Have to check if the wrapper is doing anything, who knows i may even do something.
Mostly it's probably only an interface between BOINC and the application.

[Beyond]

I'm seeing this in the Windows logs of my systems:

Activation context generation failed for "c:\program files\eFMer\tthrottle\Stress64.exe". Dependent Assembly Microsoft.VC80.MFC,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762" could not be found. Please use sxstrace.exe for detailed diagnosis.

Any idea of the cause?

[fred]

I'm seeing this in the Windows logs of my systems:

Activation context generation failed for "c:\program files\eFMer\tthrottle\Stress64.exe". Dependent Assembly Microsoft.VC80.MFC,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762" could not be found. Please use sxstrace.exe for detailed diagnosis.

Any idea of the cause?

In logs you can see more:
Type, ID, Source, When.

Next you should see: Level, Date, Source, ID

Older errors are of course not interesting.
But as Stress64 is not normally used and the error is probably related to a mismatch in an dll it needs. Should be nothing important.

[Beyond]

In logs you can see more:
Type, ID, Source, When.

Next you should see: Level, Date, Source, ID

Older errors are of course not interesting.
But as Stress64 is not normally used and the error is probably related to a mismatch in an dll it needs. Should be nothing important.

Is this helpful:

- System
 - Provider
  [ Name]  SideBySide

 - EventID 33
  [ Qualifiers]  49409
  Level 2
   Task 0
   Keywords 0x80000000000000

 - TimeCreated
  [ SystemTime]  2010-11-23T06:44:55.000000000Z
   EventRecordID 5113
  Channel Application

- EventData
  Microsoft.VC80.MFC,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762"
  c:\program files\eFMer\tthrottle\Stress64.exe

[fred]

Is this helpful:

It is, a side by side error relates to a missing or wrong library. Suspect the stressxx.exe is still linked to an older library, for the next release I will recompile it.
But this is nothing serious as stress.exe isn't normally used.

[Pepo]

QCN is a nCi task (Resources = 0.01 CPUs) and periodically (each few minutes) launches NTPdate.exe as a child process - it usually lives just a couple of seconds, sends maybe 3-4 UDP packets to Standford University, waits few seconds whether their replies succeed to come back and then exits.

Now I've noticed that my system contains 6 pieces of QCN's ntpdate_4.2.4p7c_windows_intelx86.exe processes, which are paused in memory. Launch times were

Code Select Expand

24.11.2010  11:17:39
24.11.2010  20:22:30
25.11.2010   6:15:27
25.11.2010   6:42:45
25.11.2010   8:48:56
25.11.2010   9:27:35 - seem to be pretty arbitrarily spread around.

If I resume such process, it immediately launches few threads, creates UDP connection and after 1-2 second delay it dies.

Could it be that these processes were accidentally noticed and paused (and not resumed afterwards) by TThrottle? My TTh is set to connect to BOINC client. The NTPdate executable is not listed as any matching process or its child - apparently because it is extremely short-lived and its nCi parent QCN is not listed too.

[fred]

QCN is a nCi task (Resources = 0.01 CPUs) and periodically (each few minutes) launches NTPdate.exe as a child process - it usually lives just a couple of seconds, sends maybe 3-4 UDP packets to Standford University, waits few seconds whether their replies succeed to come back and then exits.

Low usage projects are excluded. Not running, in memory, projects are always excluded.
And if you don't see anything about the project in the TThrottle window noting is done with these exe.
It will take a while for TThrottle to detect a new running program anyway.

[Pepo]

I'm testing BOINC and TTh 3.11 on a Win7 x64 notebook with some nVidia 5xx GPU. I'm starting TTh as a plain user, all CPU + GPU temperatures seem to be captured correctly (I may post the upper log part later).

But sometimes (when my session is locked or) when some other user's session is active, the GPU temperature is probably not being captured (no access??) and after unlocking my session, the GPU temperature (for the time period) is displayed as a flat line.

Is is a correct and expected behavior, or should I try to dig deeper?

[fred]

I'm testing BOINC and TTh 3.11 on a Win7 x64 notebook with some nVidia 5xx GPU. I'm starting TTh as a plain user, all CPU + GPU temperatures seem to be captured correctly (I may post the upper log part later).

But sometimes (when my session is locked or) when some other user's session is active, the GPU temperature is probably not being captured (no access??) and after unlocking my session, the GPU temperature (for the time period) is displayed as a flat line.

Is is a correct and expected behavior, or should I try to dig deeper?

I have no way of testing this right now. But I expect the problem is in the nVidia part, the driver or the interface, that's not tested for multi user.
A lot of programs act strange when you log in as an other user.