Work Unit Statistics Question

Message boards : Number crunching : Work Unit Statistics Question
Message board moderation

To post messages, you must log in.

AuthorMessage
Profile Someone537833 Project Donor
Volunteer tester

Send message
Joined: 3 Dec 17
Posts: 20
Credit: 17,911,372
RAC: 88,154
Canada
Message 1985537 - Posted: 16 Mar 2019, 22:57:54 UTC

Hello. In regards to the work unit information page, can someone explain to me what "Run time" and "CPU time" represent, and how they are related. I'm running GPU work units, using the "Special Sauce" version. Does GPU time count towards "CPU time"?

The work unit that triggered this question:
https://setiathome.berkeley.edu/workunit.php?wuid=3385538249

Both computers were using GTX 1060 3GB, running similar versions of the "Special Sauce", but drastically different "CPU times", with closer "Run Times".

Thank you.
ID: 1985537 · Report as offensive
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 8798
Credit: 774,510,879
RAC: 1,670,653
United States
Message 1985544 - Posted: 17 Mar 2019, 0:07:38 UTC - in response to Message 1985537.  

Run_time is the wall clock time. The actual elapsed time it took to compute the task. Cpu_time is the total amount of time the cpu serviced the task. For your example task you linked is an example of two hosts with different command lines. The host with approximately equal run_times and cpu_times is running the -nobs or no blocking sync parameter. This allocates a full cpu thread to feed the gpu task. It doesn't waste time in a spin loop. The other host is an example which it is NOT running the -nobs parameter. It is using cpu threads as the system allows them to become available for servicing the gpu task. For a host with few available cpu threads to service many gpu tasks or in this specific host which is running 12 gpus, it is being kind to the host cpu and not overwhelming the cpu resources by forcing all cpu threads to service the gpus and leaving some to handle normal desktop duties like having the mouse and keyboard be responsive.

If you have the spare cpu threads or are only running 1 or 2 gpus, you can speed up processing by about 5% by running the -nobs parameter with the special app.
Seti@Home classic workunits:20,676 CPU time:74,226 hours
ID: 1985544 · Report as offensive
Profile Someone537833 Project Donor
Volunteer tester

Send message
Joined: 3 Dec 17
Posts: 20
Credit: 17,911,372
RAC: 88,154
Canada
Message 1985645 - Posted: 17 Mar 2019, 17:08:30 UTC - in response to Message 1985544.  

Run_time is the wall clock time. The actual elapsed time it took to compute the task. Cpu_time is the total amount of time the cpu serviced the task. For your example task you linked is an example of two hosts with different command lines. The host with approximately equal run_times and cpu_times is running the -nobs or no blocking sync parameter. This allocates a full cpu thread to feed the gpu task. It doesn't waste time in a spin loop. The other host is an example which it is NOT running the -nobs parameter. It is using cpu threads as the system allows them to become available for servicing the gpu task. For a host with few available cpu threads to service many gpu tasks or in this specific host which is running 12 gpus, it is being kind to the host cpu and not overwhelming the cpu resources by forcing all cpu threads to service the gpus and leaving some to handle normal desktop duties like having the mouse and keyboard be responsive.

If you have the spare cpu threads or are only running 1 or 2 gpus, you can speed up processing by about 5% by running the -nobs parameter with the special app.

Thank you for the response.

The higher Run_time on the i7-6700 makes sense as it is sharing resources. However, why does the i7-6700(without -nobs) have less cpu_time than the Ryzen 5 2600 (with -nobs)?

Doing a benchmark between the two CPUs gives the 2600 a 25% better performance than the i7.
Source: https://cpu.userbenchmark.com/Compare/Intel-Core-i7-6700-vs-AMD-Ryzen-5-2600/3515vs3955

To clarify, the task runs on the i7 cpu for 29.76s, then waits for resources for a total run_time of 225.32s, where as the 2600 runs for 191.31s continuously. If the i7 had less GPUs and ran -nobs, would the run_time be the same as cpu_time (ie 29.76s)?

Thank you again for the discussion.
ID: 1985645 · Report as offensive
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 8798
Credit: 774,510,879
RAC: 1,670,653
United States
Message 1985652 - Posted: 17 Mar 2019, 17:47:18 UTC - in response to Message 1985645.  
Last modified: 17 Mar 2019, 17:55:22 UTC

The reason is the i7-6700 is running the task in a spin loop. It is not paying attention to the task when the gpu asks to be serviced and fed more data. So whenever the i7-6700 gets around to looking at the pending service request from the gpu after servicing all the other requests for a time slice, many microseconds have elapsed on the wall clock. The 2600 is actively waiting for each request for service from the gpu task and fulfills it immediately when requested. The thread is not time slicing away to service any other computer process. The more cpu_time is logged against the task means it was serviced by the cpu more. The less time logged against the task means the cpu only rarely serviced the task and the gpu thread was left waiting for another round of service requests while the wall clock kept counting. Only when the gpu thread finally shouts loud enough "service me!" to rise in priority over all other processes does the cpu finally grant the request. If you force the gpu thead to run in high priority over its normal priority, it would get serviced more often. The -nobs parameter allocates a cpu thread to just the gpu task thread and does not get pulled away for any other reason until the task finishes.

And yes, if you ran the -nobs parameter on the i7-6700 it too would have equal run_times to cpu_times. You have 8 threads, I would think that computer could spare a thread to service the gpu and still have enough left over resources to accommodate the other computer processes. It would also speed up gpu task processing on that computer.
Seti@Home classic workunits:20,676 CPU time:74,226 hours
ID: 1985652 · Report as offensive
Profile Someone537833 Project Donor
Volunteer tester

Send message
Joined: 3 Dec 17
Posts: 20
Credit: 17,911,372
RAC: 88,154
Canada
Message 1985913 - Posted: 19 Mar 2019, 1:00:22 UTC - in response to Message 1985652.  

Thank you. This all makes sense.
ID: 1985913 · Report as offensive

Message boards : Number crunching : Work Unit Statistics Question


 
©2019 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.