News:

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

Main Menu

Testing Version 3.00

Started by fred, November 02, 2010, 06:29:43 PM

Previous topic - Next topic

0 Members and 4 Guests are viewing this topic.

fred

This version departs from the previous method, of acquiring the BOINC programs to throttle.

1: Scanning the BOINC folders for files, check if they are running and throttle when needed.
2: Check with the BOINC client what programs are running an throttle when needed.

Method 2: Should mean less overhead. Presents only the program that need actual throttling. Solves the problem when both CPU and GPU work and both need throttling.

Method 1: Is still available and is used as a backup. The BOINC tab check "connect with the BOINC client" is a way to fall back on method 1, when the check is removed.


Add: Read the information about running tasks,  directly from the BOINC client.
Change: Allow programs to be throttled on both CPU and GPU.  +_abp2cuda will include the exe in the CPU and GPU throttling.

ski1939

I have the same results/comments for TT 3.00 as I had for TT 2.30 (i.e) no change

I have The BOINC tab box "connect with the BOINC client" checked

here's the log -

02 November 2010 - 14:22:10 Driver installed properly. Driver Version: 2.0

Program version: 3.00 32Bit
Microsoft Windows Vista Home Premium Edition, 32-bit Service Pack 2 (build 6002)
Vista or higher detected

Language: User: 1033 ENU ,System: 1033 ENU [/L: 1033]

Vendor ID: AuthenticAMD
Vendor: AMD
HighestIntegerValue: 00000001 - Processor Signature: 00060F82
Misc. info: 01020800
Feature Flags1 00002001
Feature Flags2 178BFBFF

Processor: AMD Turion(tm) 64 X2 Mobile Technology TL-58                   
Processor: Family: Fh, Model: 68, Stepping: 2
Processor: Revision: BH-G2, Revision: G
Processor: Socket: S1g1, Type: Turion(tm) 64 X2 Mobile
Processor: Max Die (Tjunction) Temperature: 100.0 °C
      The real Max Die (Tjunction) temperature is not this value
      This value is for calculating the temperature ONLY
      Max Die (Tjunction) is normally about Max Case + 5C
Processor: Max Case Temperature: 95.0 °C, Max Power: 0.0 W

Core Temperature: 86 °C, Raw Data: 878E7E
87ce7e,87ce7e,880e7e,880e7e,880e7e,880e7e,880e7e,880e7e,880e7e,880e7e,88
0e7e,880e7e,880e7e,880e7e,880e7e,880e7e,01ffffffffffffffff111111111111

This Processor has 2 cores and  1 temperature sensors.

BOINC:
www.worldcommunitygrid.org

You can help by reading www.efmer.eu/boinc/faq.html How can I help!
Select the send EMail button,or copy everything in this logging window and mail it to me!
boinc@efmer.eu. We use this information to improve this product.

02 November 2010 - 14:22:11 BT: Accept, Start listening for BoincTasks
02 November 2010 - 14:22:21 Number of matching Programs (Processes): 2
Cpu: wcg_c4cw_lmps_6.13_windows_intelx86, PID: 7360, Threads: 3
Cpu: wcg_c4cw_lmps_6.13_windows_intelx86, PID: 9236, Threads: 3

benDan

This works for me both tasks' CPU usage are throttled and the GPU is ignored.

Log sent
--
Dan benDan

fred

Quote from: benDan on November 05, 2010, 12:24:12 AM
This works for me both tasks' CPU usage are throttled and the GPU is ignored.
Log sent
04 November 2010 - 17:03:58 Number of matching Programs (Processes): 2
CPU:1, GPU:1, PID:6176 (3)   Slot:0   http://einstein.phys.uwm.edu/   p2030_54145_05482_0057_G198.28+03.39.C_4.dm_370
CPU:1, GPU:0, PID:2304 (3)   Slot:2   http://einstein.phys.uwm.edu/   h1_1210.00_S5R4__982_S5GC1a

Looks good to me, one task is using the GPU as well, but the throttle only activates when the temperature get too high.

ski1939

Quote from: fred on November 05, 2010, 08:13:34 AM
Quote from: benDan on November 05, 2010, 12:24:12 AM
This works for me both tasks' CPU usage are throttled and the GPU is ignored.
Log sent
04 November 2010 - 17:03:58 Number of matching Programs (Processes): 2
CPU:1, GPU:1, PID:6176 (3)   Slot:0   http://einstein.phys.uwm.edu/   p2030_54145_05482_0057_G198.28+03.39.C_4.dm_370
CPU:1, GPU:0, PID:2304 (3)   Slot:2   http://einstein.phys.uwm.edu/   h1_1210.00_S5R4__982_S5GC1a

Looks good to me, one task is using the GPU as well, but the throttle only activates when the temperature get too high.

Are these referring to a 64 bit system?

fred

Quote from: ski1939 on November 05, 2010, 09:12:20 AM
Are these referring to a 64 bit system?
Yes, but I don't think the exe are 64 bit.

ski1939

Quote from: fred on November 05, 2010, 09:21:55 AM
Quote from: ski1939 on November 05, 2010, 09:12:20 AM
Are these referring to a 64 bit system?
Yes, but I don't think the exe are 64 bit.

Do you mean that BT 0.84 and TT 3.00 32 bit exe are running on a 64 bit system and BT is displaying the temperature graph OK?

I am running them on a 32 bit system and BT does not display properly, there was no change in the BT 0.84 temperature display from TT 2.30 to TT 3.00 and my comments on TT 2.30 apply to TT 3.00 as well.   

fred

Quote from: ski1939 on November 05, 2010, 11:44:09 PM
Do you mean that BT 0.84 and TT 3.00 32 bit exe are running on a 64 bit system and BT is displaying the temperature graph OK?
I am running them on a 32 bit system and BT does not display properly, there was no change in the BT 0.84 temperature display from TT 2.30 to TT 3.00 and my comments on TT 2.30 apply to TT 3.00 as well.   
It seems the problem is only in the 32 bit BT version, so hopefully V 0.85 will solve this.
TThrottle 3.00 is using a different way to catch the exe to throttle and handles projects that use both the CPU and GPU 100% or more.

benDan

#8
I have had time to look at V3.00 and have noticed the following:
The temperature is set to 54%.
the following rules are in effect:
 if cpu temperature > 57 throttle reset 54
 if cpu temperature > 58 sound reset 54
 if cpu temperature > 60 shutdown

The temp varies from 52 to 58 several times a minute.
Throttling seems to be lost for BOINC processes.
 Number of matching Programs (Processes): 0 is shown on the programs tab.
[edit]
the following flashes on the programs tab when the throttle rule is triggered:
  Number of matching Programs (Processes): 2
Cpu: einsteinbinary_abp2_3.08_windows_intelx86.exe, PID: 3744, Threads: 3
Gpu: einsteinbinary_abp2_3.11_windows_intelx86__abp2cuda23.exe, PID: 3948, Threads: 3
---------------------------------------------------------------------------------------------------------------------   1 0 1 0
97%: Cpu: einsteinbinary_ABP2_3.11_windows_intelx86__ABP2cuda23.exe, PID: 3948, Threads: 3

[/edit]
The log shows:
86%: Cpu: einsteinbinary_ABP2_3.11_windows_intelx86__ABP2cuda23.exe, PID: 3948, Threads: 3
06 November 2010 - 09:55:50 Number of matching Programs (Processes): 0
06 November 2010 - 09:56:00 Number of matching Programs (Processes): 2
Cpu: einsteinbinary_abp2_3.08_windows_intelx86.exe, PID: 3744, Threads: 3
Gpu: einsteinbinary_abp2_3.11_windows_intelx86__abp2cuda23.exe, PID: 3948, Threads: 3
---------------------------------------------------------------------------------------------------------------------   1 0 1 0
88%: Cpu: einsteinbinary_ABP2_3.11_windows_intelx86__ABP2cuda23.exe, PID: 3948, Threads: 3
06 November 2010 - 09:56:12 Number of matching Programs (Processes): 0
06 November 2010 - 09:56:39 Number of matching Programs (Processes): 2
Cpu: einsteinbinary_abp2_3.08_windows_intelx86.exe, PID: 3744, Threads: 3
Gpu: einsteinbinary_abp2_3.11_windows_intelx86__abp2cuda23.exe, PID: 3948, Threads: 3
---------------------------------------------------------------------------------------------------------------------   1 0 1 0
--
Dan benDan

fred

Quote from: benDan on November 06, 2010, 05:00:35 PM
I have had time to look at V3.00 and have noticed the following:
The temperature is set to 54%.
the following rules are in effect:
 if cpu temperature > 57 throttle reset 54
 if cpu temperature > 58 sound reset 54
 if cpu temperature > 60 shutdown
You shouldn't set the rule so close to the set temperature. About 10 C difference is more like it.
Your log shows an continues rule throttling. The rule throttle is a last resort, not intended as a regulator.
Set them farther apart and you will see things will work a lot better.



Pepo

Quote from: fred on November 02, 2010, 06:29:43 PM
This version departs from the previous method, of acquiring the BOINC programs to throttle.

2: Check with the BOINC client what programs are running an throttle when needed.

Method 2: Should mean less overhead. Presents only the program that need actual throttling. Solves the problem when both CPU and GPU work and both need throttling.

The idea behind obtaining the list from a client is fine, but we need to fine-tune the approach. It currently has at least two pretty important drawbacks:

  • nCi (0.01 CPU and the like) tasks and (nearly idle) wrappers get throttled along the compute-intensive tasks (projects like QCN may loose a lot of sensor data, projects like DepSpid may have unnecessary delays in network communication, projects like WUProp and XtremLab might loose other tasks' transitions between states, etc.)
  • the compute-intensive tasks behind wrappers do not get throttled at all.

Tasks behind wrappers can still be manually added to the throttled list, but the list of exceptions from throttling is already inaccessible.
Peter

fred

Quote from: Pepo on November 12, 2010, 08:36:39 AM
The idea behind obtaining the list from a client is fine, but we need to fine-tune the approach. It currently has at least two pretty important drawbacks:

  • nCi (0.01 CPU and the like) tasks and (nearly idle) wrappers get throttled along the compute-intensive tasks (projects like QCN may loose a lot of sensor data, projects like DepSpid may have unnecessary delays in network communication, projects like WUProp and XtremLab might loose other tasks' transitions between states, etc.)
  • the compute-intensive tasks behind wrappers do not get throttled at all.
Tasks behind wrappers can still be manually added to the throttled list, but the list of exceptions from throttling is already inaccessible.
I will add: Don't throttle CPU on low usage projects. < 0.5 CPU.
Projects behind wrappers should be recognized. Check BT task properties for the PID and check if the PID (Process ID) is the right one and is actually running.
You can always go back to the "old" method.

Pepo

Quote from: fred on November 12, 2010, 08:56:57 AM
Quote from: Pepo on November 12, 2010, 08:36:39 AM
The idea behind obtaining the list from a client is fine, but we need to fine-tune the approach. It currently has at least two pretty important drawbacks:

  • nCi (0.01 CPU and the like) tasks and (nearly idle) wrappers get throttled along the compute-intensive tasks (...)
  • the compute-intensive tasks behind wrappers do not get throttled at all.
Projects behind wrappers should be recognized. Check BT task properties for the PID and check if the PID (Process ID) is the right one and is actually running.
Currently there are these listed tasks:
12 November 2010 - 10:21:44  Počet zhodných programov (procesov): 6
CPU:1, GPU:0, PID:8104 (3) Slot:1 http://cpdnbeta.oerc.ox.ac.uk/ famous_s303_599_200_000222072
CPU:1, GPU:0, PID:2304 (3) Slot:7 http://www.primegrid.com/ llrCUL_66278480
CPU:1, GPU:0, PID:6532 (6) Slot:3 http://qcn.stanford.edu/sensor/ qcnaa_003950
CPU:1, GPU:0, PID:3404 (3) Slot:0 http://wuprop.boinc-af.org/ wu_1287777243_166101
CPU:0, GPU:1, PID:1208 (3) Slot:5 http://setiweb.ssl.berkeley.edu/beta/ 18no09aj.27102.19295.6.13.84
CPU:1, GPU:0, PID:5452 (4) Slot:6 http://spin.fh-bielefeld.de/ 21_Fe30_map_1974_803


whereas PID:8104 is projects\cpdnbeta.oerc.ox.ac.uk\famous_6.11_windows_intelx86.exe with current dir in slots\1\ and child process PID:8344 is projects\cpdnbeta.oerc.ox.ac.uk\famous_um_6.11_windows_intelx86.exe with current dir in projects\cpdnbeta.oerc.ox.ac.uk\famous_s303_599_200_000222072\,

and similarly PID:2304 is projects\www.primegrid.com\primegrid_llr_wrapper_5.11_windows_intelx86.exe with current dir in slots\7\ and child process PID:7660 is slots\7\primegrid_llr_5.09_windows_intelx86.exe with current dir in  slots\7\.

Both wrappers get throttled but neither of their "payloads".

The goodie is that TTh does not attempt to throttle preempted tasks.
The drawback could be that when some rogue task ignores it should be preempted or it "gets lost" and the client looses track on it, it would continue to crunch unthrottled. But this happens rarely and possibly neither the older method would throttle it, if it would be gone from client_state.xml?
Peter

fred

Quote from: Pepo on November 12, 2010, 09:49:52 AM
Both wrappers get throttled but neither of their "payloads".
I may need to include the child processes.

fred

Quote from: Pepo on November 12, 2010, 08:36:39 AM

  • nCi (0.01 CPU and the like) tasks
I now include the child processes.
But tasks with less that 1 CPU aren't throttled as it is now.