News:

Follow BoincTasks on Twitter Facebook        Visit our website here.
BoincTasks cloud login is working again

Main Menu

Testing Version 3.20

Started by fred, March 02, 2011, 09:23:15 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

fred

Changed: Throttling is now using a random scattering pattern, to avoid simultaneous throttling of all cores.
Changed: The default minimum CPU throttle value is 2%, was 5%.
Changed: All exe and dll files are now signed.
Fixed: Stress(64).exe is no longer using the side by side dll's

Pepo

#1
From just a short testing:

  • TTh's CPU usage now appears much higher (initially 3%, after few minutes 12-20%, on 4 cores, BOINC using 3 cores + GPU, throttling is around 25-50%), with absolute majority of it (around 98%) being kernel time.
  • TTh is leaking handles, it allocates and keeps a lot of identical thread handles to (running) BOINC tasks - many dozens per second.
  • Page Fault Delta was initially ~30 000/s, now 120 000-200 000/s

"There is something rotten in the......"

[edit]Just to add - Win7 x64, TTh runs under a plain user account, the same as BOINC, and this all is happening just while throttling is active.[/edit]
[edit]TTh is also leaking memory. Slowly, continuously, systematically, ~3 MB/3 hours, even with no throttling.[/edit]
Peter

Beyond

Quote from: fred on March 02, 2011, 09:23:15 PM
Changed: Throttling is now using a random scattering pattern, to avoid simultaneous throttling of all cores.
Does TThrottle now throttle GPUs individually so that only the one with high temps is affected?

fred

Quote from: Beyond on March 03, 2011, 02:51:15 PM
Quote from: fred on March 02, 2011, 09:23:15 PM
Changed: Throttling is now using a random scattering pattern, to avoid simultaneous throttling of all cores.
Does TThrottle now throttle GPUs individually so that only the one with high temps is affected?

Not yet, I have to be at home to do that.

Pepo

I had to disable throttling overnight. Now, after a reboot, TTh is throttling 5 matching processes to ~50%, Page Fault Delta is back to usual ~29 000/s, CPU usage around 3%, leaking ~70 handles/10 sec. I have no idea what this higher-impact-situation was. But still the handles... how long would Windows survive unattended?

---

With previous TTh versions, I've been able to observe the throttled processes being paused for brief moments (seen as grayed lines in Process Explorer). Not anymore. Is TTh not pausing the whole processes anymore, but their single threads (hence the observed thread handles)? (Probably, I've seen their states flipping between Ready, Running and Wait:Suspended, with the Wait:Suspended state proportional to the amount of throttling. Is it much less overhead to suspend a remote process' threads than the whole process?)
Peter

fred

Quote from: Pepo on March 04, 2011, 02:27:49 PM
I had to disable throttling overnight. Now, after a reboot, TTh is throttling 5 matching processes to ~50%, Page Fault Delta is back to usual ~29 000/s, CPU usage around 3%, leaking ~70 handles/10 sec. I have no idea what this higher-impact-situation was. But still the handles... how long would Windows survive unattended?

---

With previous TTh versions, I've been able to observe the throttled processes being paused for brief moments (seen as grayed lines in Process Explorer). Not anymore. Is TTh not pausing the whole processes anymore, but their single threads (hence the observed thread handles)? (Probably, I've seen their states flipping between Ready, Running and Wait:Suspended, with the Wait:Suspended state proportional to the amount of throttling. Is it much less overhead to suspend a remote process' threads than the whole process?)
I haven't been able to detect any memory leaks.
But there seems to be something going on with the handles.
As handles are pretty small, this may go on for months.

Throttling can only be done on treads, so a process can't be suspended as such.
A process is more like a collection of threads, and it's always the threads that do something.

The detection: it may be that the frequency is a bit higher, so it's no longer detected.

Pepo

Quote from: fred on March 04, 2011, 09:06:33 PM
Quote from: Pepo on March 04, 2011, 02:27:49 PM
... leaking ~70 handles/10 sec. ... But still the handles... how long would Windows survive unattended?
But there seems to be something going on with the handles.
As handles are pretty small, this may go on for months.
My previousWinXP machines have usually been locking up upon reaching some 100 000 handles... (with existing system and apps usually having 30-40 000)
Peter

fred

Quote from: Pepo on March 04, 2011, 09:35:43 PM
My previousWinXP machines have usually been locking up upon reaching some 100 000 handles... (with existing system and apps usually having 30-40 000)
I've done some testing and can't fine any handle problems. On my computer the handle count is somewhat stable.
But how do you know it's TThrottle, there are lots of background tasks around.

Pepo

Quote from: fred on March 04, 2011, 11:23:24 PM
I've done some testing and can't fine any handle problems. On my computer the handle count is somewhat stable.
But how do you know it's TThrottle, there are lots of background tasks around.
You can check the per-process handle count even in the Task Manager.
With Process Explorer (or Process Hacker) I can see also the complete list of the handles, their names, addresses, values, types, etc. So, no doubt which of them belong to TTh, how many are bound to the tasks' threads, etc.
(I've also checked Windows' native Resources Monitor. It also lists per-process threads, but (why??) is omitting the thread handles.)

Today I've thoroughly checked TTh 3.11 on other Win7 x64 machine (just 1 of 4 cores enabled for BOINC, running 1 SETI and 1 nCi task). My outsider's observations:

Both tasks had 3 threads. While throttling, there were 3 thread handles for each of the throttled tasks (I've been varying the settings, which tasks to throttle and which not). While throttling, it seemed that approximately once in a 2-3 seconds, new thread handles were created for each throttled process' task and the old ones were discarded at the same moment. As mentioned previously, each task's threads' states were flipping between Ready, Running and Wait:Suspended, with the Wait:Suspended state proportional to the amount of throttling. The handle count kept steady. (IIRC when stopping the throttling, TTh threw away all BOINC tasks' thread handles.)

After installing TTh 3.20, nearly all was the same. Just that (exactly observed on SETI task) each time 3 new thread handles were created (one for each thread), but just one old corresponding handle got deleted. (But probably not exactly, because after running some 20 minutes long, for some 600 handles for 2 of the threads, I've got 17 handles for the third thread.) Thus the leakage, in this case a handle/2-3 sec/per task.


I've got an idea on the paused processes I've been asking:
Quote from: fred on March 04, 2011, 09:06:33 PM
Quote from: Pepo on March 04, 2011, 02:27:49 PM
With previous TTh versions, I've been able to observe the throttled processes being paused for brief moments (seen as grayed lines in Process Explorer). Not anymore. Is TTh not pausing the whole processes anymore, but their single threads (hence the observed thread handles)? (Probably, I've seen their states flipping between Ready, Running and Wait:Suspended, with the Wait:Suspended state proportional to the amount of throttling. Is it much less overhead to suspend a remote process' threads than the whole process?)
Throttling can only be done on treads, so a process can't be suspended as such.
A process is more like a collection of threads, and it's always the threads that do something.
The TTh 3.11 was suspending all threads unisono. Probably if Process Explorer notices that a process has all its tasks suspended, it displays the whole process being in a Suspended state. When I suspend some process manually in Process Explorer, I can then see that all threads of the process are in the same Wait:Suspended state.
The TTh 3.20 apparently (or mostly) never suspends all threads of a process at the same time. As a side-effect, Process Explorer never assumes it being in a Suspended state :)

Sorrrrry for yet another long SPAM ;D
Peter

fred

Quote from: Pepo on March 05, 2011, 05:34:22 PM
Sorrrrry for yet another long SPAM ;D
Almost  ;D.
Ok I can confirm the leaking of handles, not sure where, but will do some rewriting.