Message boards :
Number crunching :
8 hours, 42 minutes elapsed, 3 hours CPU time
Message board moderation
| Author | Message |
|---|---|
|
Send message Joined: 5 Dec 12 Posts: 84 Credit: 1,663,883,415 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
I'm running two jobs on my main crunching PC, the new GAINNI work units and e34s5_e12s13p0f122-GERARD_FXCXCL12RX_941195_1-0-1-RND8719. The CPU tasks have been running World Community Grid (UGM). My task manager says nothing of note is running in the background. Both tasks have a major discrepancy between elapsed time and crunching time. This is a new problem for me, I'm pretty sure it wasn't happening a week ago. Advice would be appreciated. |
caffeineyellow5Send message Joined: 30 Jul 14 Posts: 225 Credit: 2,658,976,345 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
The GIANNI tasks run significantly longer. It is not a problem on your PC, BOINC, or the project. It is just longer running tasks. If the time completed based on the percent completed will finish within the timeout period, let it run. They are easy to fail though, so make sure there is no excessive restarting, tinkering, or power inconsistencies. 1 Corinthians 9:16 "For though I preach the gospel, I have nothing to glory of: for necessity is laid upon me; yea, woe is unto me, if I preach not the gospel!" Ephesians 6:18-20, please ;-) http://tbc-pa.org |
|
Send message Joined: 5 Dec 12 Posts: 84 Credit: 1,663,883,415 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
Yeah, no problem if a tasks runs long. I'm concerned that it's spending most of its time idling, given that the task details report crunching time less than half of the real life elapsed time. Not to mention that this issue seems contagious, because my Gerard WU's now seem to have the same problem. |
|
Send message Joined: 5 Jan 09 Posts: 670 Credit: 2,498,095,550 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
Are you certain that your WCG task(s) was not accessing the GPU at the same time? |
Retvari ZoltanSend message Joined: 20 Jan 09 Posts: 2380 Credit: 16,897,957,044 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
I'm running two jobs on my main crunching PC, the new GAINNI work units and Do you mean that not even the WCG tasks? Both tasks have a major discrepancy between elapsed time and crunching time. What do you mean by "elapsed time" and "crunching time"? This is a new problem for me, I'm pretty sure it wasn't happening a week ago. If the above two is what you can see on the task list page of your hosts, then this discrepancy in "CPU time" and "Run Time" is normal for a host without the SWAN_SYNC environmental value. |
|
Send message Joined: 5 Jan 09 Posts: 670 Credit: 2,498,095,550 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
Real time will also include the amount of time the WU has been on your host which is obviously your cache size. |
|
Send message Joined: 5 Dec 12 Posts: 84 Credit: 1,663,883,415 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
A few replies and an update: Yes, World Community Grid is not accessing my GPU. They haven't had any GPU projects in the last few years. The WCG tasks are running in the background; when I looked at the task manager, I saw nothing unexpected. I have not reserved any cores for the GPU. I may reserve a core if the run times are night and day. I put plenty of value on the CPU tasks, because they publish their proposal in advance, so I know what I'm contributing towards and can quantify the progress (Zika, Cancer, HIV, etc). Retvari, you are correct, the numbers I'm getting are if you highlight a task and hit the 'properties' button in the BOINC manager. I am used to seeing a small discrepancy between duration and runtime, and now it's a ratio of one to three. It's not a number influenced by Cashe size. As for the update, I'm now running a mixture of WCG projects again. I've got a GIANNA task on its 27th hour, two hours to go, on my GTX 970. CPU time is less then ten hours. |
skgivenSend message Joined: 23 Apr 09 Posts: 3968 Credit: 1,995,359,260 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Even if you could fully and accurately quantify the progress of a projects scientific research and your contribution towards it, comparing one project to another is qualitative and what the research might lead to in years to come is speculative. On an i7 you would be freeing up one thread (not core). Doing so should improve GPU performance (reduce the times), but your times are quite good anyway. While threads are entities in themselves they don't entirely operate in isolation; shared cache, controller, queues/buses. The difference in overall CPU performance of a i7-4930K crunching 12 CPU tasks vs 11 CPU tasks is probably negligible compared to the GPU performance improvements that come from not having the CPU constantly over-saturated (in my qualified opinion). For a GPUGrid task the 'Elapsed' time is basically the time it ran on the GPU. The CPU time is the time it ran on the CPU (not the GPU). 'Elapsed' time actually includes a few seconds to load the task before it starts and a few seconds at the end (but doesn't include any time is sat in the work queue, was paused, the download, upload or report time periods). FAQ's HOW TO: - Opt out of Beta Tests - Ask for Help |
|
Send message Joined: 1 Jan 15 Posts: 1168 Credit: 12,311,898,501 RAC: 246,185 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
The difference in overall CPU performance of a i7-4930K crunching 12 CPU tasks vs 11 CPU tasks is probably negligible compared to the GPU performance improvements that come from not having the CPU constantly over-saturated (in my qualified opinion). I have tested this, and can fully confirm what you are saying |
Retvari ZoltanSend message Joined: 20 Jan 09 Posts: 2380 Credit: 16,897,957,044 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
The difference in overall CPU performance of a i7-4930K crunching 12 CPU tasks vs 11 CPU tasks is probably negligible compared to the GPU performance improvements that come from not having the CPU constantly over-saturated (in my qualified opinion). In my experience under Windows XP x64 on a system which has "only" dual channel memory subsystem (i3-4160, i7-4770k, i7-4790k) if there is more than 1 another CPU task running (usually rosetta@home, or Einstein@home), the GPUGrid task (SWAN_SYNC on) suffers demonstrable performance loss (especially those which use more CPU like the GIANNI_D3C36bCHL). It is better not to run CPU tasks at all, but the improvement in the performance of the GPUGrid task switching from 1 to 0 CPU tasks is much less than of switching from n CPU tasks to 1 CPU task (n>1). The lesser (socket 115x) i7 CPUs are not significantly better from this point of view than the i3 CPUs. The i7 has 8MB L3 cache, while the i3 has only 3MB (or 4MB), but it seems to me that only 1 CPU task could saturate both kinds of CPU concerning GPU tasks. |
|
Send message Joined: 26 Dec 13 Posts: 87 Credit: 1,292,358,731 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
As I long ago had noticed, the degree of GPU utilization depends on the degree of CPU load. In order to neutralize the impact of BOINC CPU tasks from other projects, as well as any applications on my computer (I don't have dedicated machine for this purpose), I just raise priority of GPUGRID process in Process Explorer to High(13). GPUGRID in this mode does not affect the responsiveness of the system and not resource-intensive graphics tasks (watching video / not heavy 3D-graphic games). This allows me to keep GPU load during computation at constant level, without periodic performance gaps. Given that my GTX 660 for long runs task requires on average 24 hours to perform, such manual adjustment is not too annoying for me. Example |
|
Send message Joined: 3 Nov 15 Posts: 38 Credit: 6,768,093 RAC: 0 Level ![]() Scientific publications
|
HyperThreading cores are not full cores and if one thread of a cure is fully loaded with FPU code the other will see a performace degradation and lag. GPUGrid applications usually don't use cpu much (about 5%), they run at the GPU. The "crunching time" measures processor usage not GPU, by the task and should be lower than "elapsed time" (without the swan_sync hack). But the CPU has important role to feed the GPU with work and if cpu lags or is used by other process the gpu sits idle. Raising priority of "acemd" process is good way to increase gpu usage (which should be above 80%). If you set SWAN_SYNC environment variable the acmd process is going to use (or waste) 100% CPU just asking the gpu whether it has finished and should be fed another tiny piece of work from the WU. But then OS process scheduler will think this task is CPU bound and reduce its dynamic priority! BOINC runc gpu apps at higher priorith than cpu appc (at least on linux). You can try disabling hyperthreadig (decreased lag). My thesting found: Increase process priority increase gpu load, disabling HT increase GPU load even further, stopping cpu compotation increases too. But when HT disabled and realtime priority cpu load does not affect GPU load.
|
caffeineyellow5Send message Joined: 30 Jul 14 Posts: 225 Credit: 2,658,976,345 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
I just raise priority of GPUGRID process in Process Explorer to High(13).Do you mean Process Explorer or Process Hacker? In PE you can set it per WU but need to keep going back and resetting it with new tasks. But with PH you can set it to "save" it and it will automatically set it each new download. Incidentally in anything Vista and beyond you can set the IO priority too in disk writes. (Note: I can't speak to the system stability as there is a warning even on install in going Kernel Mode or User Mode and some have said setting IO priority intrinsically makes things unstable. I use it on my systems and my laptop doesn't get errors or reboots. The other systems, I feel there is hardware or something wrong that is not the PH.) 1 Corinthians 9:16 "For though I preach the gospel, I have nothing to glory of: for necessity is laid upon me; yea, woe is unto me, if I preach not the gospel!" Ephesians 6:18-20, please ;-) http://tbc-pa.org |
|
Send message Joined: 26 Dec 13 Posts: 87 Credit: 1,292,358,731 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
I just raise priority of GPUGRID process in Process Explorer to High(13).Do you mean Process Explorer or Process Hacker? In PE you can set it per WU but need to keep going back and resetting it with new tasks. But with PH you can set it to "save" it and it will automatically set it each new download. Incidentally in anything Vista and beyond you can set the IO priority too in disk writes. I use Process Explorer and manually increase priority for each new task. As I wrote above, for me it's not too annoying (1 time in 24 hours). I thought about a tool with the same functionality as Process Hacker, but did not know specific tools. Thank you for example, I'll try it! |
|
Send message Joined: 26 Dec 13 Posts: 87 Credit: 1,292,358,731 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
But with PH you can set it to "save" it and it will automatically set it each new download. As I understand it, this setting is valid only while running Process Hacker. Is there any possibility to save this setting at OS level? |
caffeineyellow5Send message Joined: 30 Jul 14 Posts: 225 Credit: 2,658,976,345 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
Once it is set in the PH, then PH can be closed and it will keep till the next task starts, just like PE. I know it is tapping into the OS or the Kernel to do this and I don't know if there is a manual setting or hack that can do it. I jsut run PH with Windows and set its own priorities within itself to Low and Idle and set the refresh to 10 seconds under "View". This minimalizes the impact of running it minimized and after 10 seconds or so will change the priorities of the new tasks. I still use PE as my Task Manager replacement in settings. In addition to increasing the prios of the tasks themselves, I also increase the BOINC Manager and BOINC.exe so there is a full optimization of all working parts of getting the work done. |
|
Send message Joined: 26 Dec 13 Posts: 87 Credit: 1,292,358,731 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
I meant that PH must be run at the moment of starting new task, to apply high priority from previously saved settings. I thought that PH can apply some hack at OS level and do not need to keep it running. However it is enough useful. Even at high refresh rates(Priorety 13) and minimized to tray, PH consumes average 0.05-0.1% of CPU. Besides, if it used only for that purpose, then it is possible to just disable auto refresh and then it's consumption will be <0.01% of CPU. |
©2026 Universitat Pompeu Fabra