| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Completed Research
Forum: Help Fight Childhood Cancer Project Forum
Thread: "Monster" Wus ? |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 50
|
|
| Author |
|
|
Sgt.Joe
Ace Cruncher USA Joined: Jul 4, 2006 Post Count: 7846 Status: Offline Project Badges: 
|
For HFCC I am quite sure that the number of operations is the same for all WUs, or close to the same value anyway. You may know better than I, but given the variation I see in my results for this project I surmise the number of operations per WU must vary as some dockings are more difficult than others. Perhaps one of the project scientists could weigh in on this issue. Cheers
Sgt. Joe
*Minnesota Crunchers* |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges: 
|
For HFCC I am quite sure that the number of operations is the same for all WUs, or close to the same value anyway. Well, it's maybe so, but WCG is "constantly" adjusting the estimates... I especially remember seeing some unstarted Rice-wu sitting in the queue, having different estimated run-times, since all wasn't downloaded at the same time... The DCF is adjusted when a WU completes and is the varying factor. As you can see its value depends on what has happened for the last processed WU and not on what is expected to happen. When a WU runs longer than what was estimated by the client the DCF is adjusted "full size", i.e. queued WUs of the same project will generally be estimated at the duration of the WU which has taken longer. This behaviour depends on client-version. In most resent clients, it's not adjusted upwards fully at once, if the new DCF isn't too far off from the old one. In older clients, it's always set to the new max DCF if there are any. When a WU runs faster than estimated the DCF is decreased by only a small percentage of the difference. Adjusted down with 10% if not too far off difference, but only 1% if you've suddenly got a very small value for a task, since this normally means a task terminated much earlier than normal. A good example on this is HCMD2, there especially a child can finish faster than expected.  "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
Hypernova
Master Cruncher Audaces Fortuna Juvat ! Vaud - Switzerland Joined: Dec 16, 2008 Post Count: 1908 Status: Offline Project Badges: 
|
Jean you are perfectly right. It is a plan to have in the end the entire solar system to help advance reasearch.
----------------------------------------But how long it will take who knows.  In 2010 are planned Mercury Earth and Mars.  The final timing is not clear yet.  |
|||
|
||||
|
JmBoullier
Former Community Advisor Normandy - France Joined: Jan 26, 2007 Post Count: 3716 Status: Offline Project Badges:
|
For HFCC I am quite sure that the number of operations is the same for all WUs, or close to the same value anyway. You may know better than I, but given the variation I see in my results for this project I surmise the number of operations per WU must vary as some dockings are more difficult than others. In the context of this post I was obviously talking of the number of operations used by the client for estimating the total duration, i.e. the number attached to the WU when generating it. Which, I think, is not adjusted very often for the HFCC project (as opposed to HCMD2). Cheers. Jean. |
||
|
|
JmBoullier
Former Community Advisor Normandy - France Joined: Jan 26, 2007 Post Count: 3716 Status: Offline Project Badges:
|
Ingleside,
----------------------------------------I am currently running the recommended 6.10.17 under Ubuntu 9.10 and the DCF adjustment routines seem to be even worse than before. I agree that running HCMD2 only in this device does not help but after a (full) surge from an average 2.5 hours to 7 hours I am back to only 3.5 hours after 19 WUs in the average 2.5 duration. It's probably the value of "far" and/or "not too far" which is not the same for us. At least this problem is just an inconvenience. More annoying is the task list display of Boinc Manager which stops refreshing after a few seconds if I have no activity in BM, i.e. if the window is in the background or if I don't touch the mouse or the keyboard when it is the active window. And it the machine stays idle in this status for too long the keyboard and mouse are no longer operational. Fortunately the apps and the client go on working backstage though, but the machine needs a reboot to become usable again.  |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
I think that each task has the same amount of targets/attempts in a batch, but given it's a non-deterministic calculation, always trying to find a best / lowest energy, each of these can take longer or shorter. That's why each batch a few test results are mixes into the production stream to find out how long they take, but if that is within reason i.e. 7 hour mean target and the test jobs give out e.g. 8 hours, the techs will not change the cutting process i.e. let it run.
----------------------------------------BOINC btw does not know concepts of fixed run time. It just sees estimated flops in the header and these are dynamically adjusted based on prior days productions... and since work is cut days before they actually get into the feeder it still could be off. From the big Sunday morning thumb ;P
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges:
|
Ingleside, I am currently running the recommended 6.10.17 under Ubuntu 9.10 and the DCF adjustment routines seem to be even worse than before. I agree that running HCMD2 only in this device does not help but after a (full) surge from an average 2.5 hours to 7 hours I am back to only 3.5 hours after 19 WUs in the average 2.5 duration. It's probably the value of "far" and/or "not too far" which is not the same for us. HCMD2 being "all over the place" isn't really an effect of client-version, a quick look on my 5 last results gives a variation between 1.66 h and 8.97 h, so DCF also being "all over the place" isn't unexpected. Hmm, it doesn't seem that HFCC is much better, since from the 6 last, it's variated between 6.27 h and 10.41 h. If these also had different fpops_est I don't know. At least this problem is just an inconvenience. The estimates being incorrect is a problem if you're running with a large cache, or multiple projects. More annoying is the task list display of Boinc Manager which stops refreshing after a few seconds if I have no activity in BM, i.e. if the window is in the background or if I don't touch the mouse or the keyboard when it is the active window. And it the machine stays idle in this status for too long the keyboard and mouse are no longer operational. Fortunately the apps and the client go on working backstage though, but the machine needs a reboot to become usable again. Hmm, probably a linux-only problem, possibly only with your particular linux-distribution... "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." |
||
|
|
Sekerob
Ace Cruncher Joined: Jul 24, 2005 Post Count: 20043 Status: Offline |
Now try for 1 minute to fathom 1 HFCC running off a physical core and the second on a HT thread, of an I7. Would the runtimes be different? I've rigged the jury and know the answer.
----------------------------------------
WCG
Please help to make the Forums an enjoyable experience for All! |
||
|
|
Ingleside
Veteran Cruncher Norway Joined: Nov 19, 2005 Post Count: 974 Status: Offline Project Badges:
|
Now try for 1 minute to fathom 1 HFCC running off a physical core and the second on a HT thread, of an I7. Would the runtimes be different? I've rigged the jury and know the answer. Well, I've not specifically looked on HFCC, but atleast in other BOINC-projects, you'll get roughly the same cpu-time on all 8 tasks running in parallell, as long as it's similar-type-tasks, even you've only got 4 "real" cores. ** But, the results can be heavily influenced by if you're running one "hard" task + 7 "easy" tasks, or if you're running 8 "hard" tasks. One example showing this is, one VHAR-wu + 7 "normal" AR takes roughly 45 minutes for the VHAR, while 8 VHAR-wu in parallell takes roughly 1 hour. So, if you're somehow runs-out of enough work to keep all 8 threads busy, you can get large variations. But, I've here expected you'll all the time keeps all 8 "cores", real and virtual, busy with work. *** ** Example, 7 Hadam3p beta-models running in parallell with various other tasks as 8th thread, there the end-times was: 3.8285 days 3.8102 3.7983 3.7683 3.7692 3.8280 7th generated an error so end-time isn't correct. Max difference between tasks, 1.6%. *** Small benchmark, again with Hadam3p, running the same model from start to same point: 1 core: 2.17 s/TS. 4 cores: 2.95 s/TS. 8 cores: 4.92 s/TS. => only 3.5x higher production compared to single-core. "I make so many mistakes. But then just think of all the mistakes I don't make, although I might." [Edit 1 times, last edit by Ingleside at Dec 13, 2009 6:09:27 PM] |
||
|
|
JmBoullier
Former Community Advisor Normandy - France Joined: Jan 26, 2007 Post Count: 3716 Status: Offline Project Badges:
|
Now try for 1 minute to fathom 1 HFCC running off a physical core and the second on a HT thread, of an I7. Would the runtimes be different? This view of 8 cores with four forcibly being virtual since only four can be real is a "romantic" one, or better a BOINC-oriented one. In reality there are four physcal cores, each fed by two threads for optimizing the use of their numerous specialized units and each thread has the same value in this exercise. Therefore if you start the same task eight times in such a processor all eight should end with about the same CPU time if the operating system is not trying to play tricks of its own. Until I decide to have an i7 myself I leave it to happy i7 owners to confirm my theory. Or not. Cheers. Jean. Edit: Typo ---------------------------------------- [Edit 1 times, last edit by JmBoullier at Dec 14, 2009 3:20:58 PM] |
||
|
|
|