Message boards :
Graphics cards (GPUs) :
WUs with double runtime?
Message board moderation
| Author | Message |
|---|---|
KokomikoSend message Joined: 18 Jul 08 Posts: 190 Credit: 24,093,690 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
What is changed, that the WUs now have double runtime for the same credit? On my GTX295 a runtime of 37.000 seconds is normal, but the actual WUs are running 75.000 seconds and gave the same credit. The wall clock time has changed from 9.5 hours to over 20 hours. 1243984 with 75270.441 s 1235901 with 37362.348 s
|
GDFSend message Joined: 14 Mar 07 Posts: 1958 Credit: 629,356 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() |
These two wus should take the same time to complete. Maybe, the gpu was in use or something like that. gdf |
KokomikoSend message Joined: 18 Jul 08 Posts: 190 Credit: 24,093,690 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
No, no game playing in this time. The next WU (616-GIANNI_BIND001-28-100-RND7903_1) is already running since 22:25 hours and has still to go for 4:24. The card is running under Vista 64 with driver 190.62. The BOINC version was since friday evening 6.10.4. I have just downgraded to 6.10.3.
|
Paul D. BuckSend message Joined: 9 Jun 08 Posts: 1050 Credit: 37,321,185 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
There is an intermittent issue where tasks take double or more time to complete. It showed up in the early 6.6.? series and has so far proved impossible to pin down as to the cause or reason. It can affect bout GPU and CPU tasks. USUALLY a reboot clears up the situation. There was nothing interesting in the log files the last time I had one of those and I had just about every log option on. Visual proof, like pictures of long running tasks, are of course not enough to convince UCB that there is a potential issue. Though lord knows I tried ... |
robertmilesSend message Joined: 16 Apr 09 Posts: 503 Credit: 769,991,668 RAC: 0 Level ![]() Scientific publications ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]()
|
I encountered a similar problem with Rosetta@home CPU workunits, but for those the normal log files referred to a lockfile problem, so you might want to make sure you checked for this. First, a workunit failed for some reason that kept it from deleting its lockfile. BOINC then failed to recognize this as sufficient reason not to use that slot until something like a reboot deleted the lockfile instead. Then all following workunits, apparantly from any project, that tried to write a checkpoint in the directory for that slot failed because the lockfile prevented this from working. I don't know if this problem occured only when running under Vista SP2, but that's where I saw it. The problem was more likely to occur if BOINC was set to use less than 100% of the CPU time, such as 90%. However, since installing BOINC 6.6.36, I don't remember seeing this problem any more. The best I can tell, BOINC 6.6.36 is more likely to create extra slots, so there's some chance they have already tried to fix it by some new code in that version to tell it not to reuse any slots with a lockfile left over from a previous workunit. Just in case they didn't, you may want to add some code to GPUGRID that checks for a lockfile it didn't create at the start of the workunit, and reports whether it found one in a way that will be returned even if the workunit is unable to write any checkpoints. Another idea of something to add - fairly frequently, check the clock speeds of the GPU and the number of processors it has available, and if there have been significant changes, report them. |
©2025 Universitat Pompeu Fabra