Message boards :
Number crunching :
Work Unit Statistics Question
Message board moderation
Author | Message |
---|---|
Someone537833 Send message Joined: 3 Dec 17 Posts: 21 Credit: 38,445,632 RAC: 113 |
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. |
Keith Myers Send message Joined: 29 Apr 01 Posts: 13164 Credit: 1,160,866,277 RAC: 1,873 |
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 A proud member of the OFA (Old Farts Association) |
Someone537833 Send message Joined: 3 Dec 17 Posts: 21 Credit: 38,445,632 RAC: 113 |
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. 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. |
Keith Myers Send message Joined: 29 Apr 01 Posts: 13164 Credit: 1,160,866,277 RAC: 1,873 |
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 A proud member of the OFA (Old Farts Association) |
Someone537833 Send message Joined: 3 Dec 17 Posts: 21 Credit: 38,445,632 RAC: 113 |
Thank you. This all makes sense. |
©2024 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.