Too fast
21 Jan 2006 20:34:09 UTC
Topic 190653
(moderation:
I have a dual-core athlon-64 computer that has been stopped by E@H for a 6-hour enforced delay because it completed its daily alotment of 32 units before 24 hours. It has been running some "albert" units in about 4000 sec or 1.1 hours for each unit for each core. That means in 24 hours it should complete 2*(24/1.1)= 43.6 units with both cores running.
I think there might be some problem with the alotment calculation at E@H that assigned 32 unts max per day.
I can delete the installation & re-install if that is the only fix.
[This computer is named XBOX...]
ADDMP
Too fast
)
No it's nothing wrong with your install. The problem is that unlike Einstiens which were fairly consistant in size Alberts can vary by a factor of 4, and the scheduler doesn't take the difference into account when handing out work. You're not the first person to have problems with a really fast machine and short Alberts, some highend macs've been burned as well. For the moment the best you can do is to add a 2nd project and set the work distribution to 99/1. The 2nd project will then (almost) only run when you're out of work for e@h, and a starvation attack here will put it far enough ahead that the 2nd project won't do anything at all for a time.
RE: I have a dual-core
)
Looking at the scheduler logs (available by following on-line links) I see that your computer has:
So really the question in my mind is, why doesn't this machine have a LOT more results on it? And why isn't it requesting more than 1800 seconds of work?
PS: one of your intel boxes is reporting results with zero CPU time. Consider updating BOINC to fix this problem.
Director, Einstein@Home
RE: No it's nothing wrong
)
Thanks for that news & suggestion. I had some trouble getting BOINC to allow me to run two E@H versions at once, but I now have both a linux/wine/windows version and a native linux version running simultaneously at different levels of "nice"ness. That should be OK, but I'll see what happens as they return results.
ADDMP
RE: RE: I think there
)
RE: But nevertheless, I
)
I've bumped up the per cpu quotas by another factor of two. Let's see if that fixes this problem.
Director, Einstein@Home
Thanks, Bruce, for increasing
)
Thanks, Bruce, for increasing the MDQ to 32.....our dual core and faster 64s will be happy again! I can also increase the E@H share on these machines back to the pre-'Albert' levels. Tweakster will be happy and warm as well!....Cheers, Rog.
RE: I've bumped up the per
)
OMG, Sir, no, tell me you didn't! At least not without implementing a "abort queued work at uninstall" bit, AND returning to a replication of 4. Already, we have a huge and increasing quantity on "pendings" due to the normal numbers of project dropouts and eyes-bigger-than-their-bellies WU hoggers. Your databases will be bloated, and it will not be an unusual case to have folks waiting a month or more for pending credits to be resolved. This will be a headache of epic proportions, and even it quickly reversed, the "hangover" will last for a month.
Dr. Allen, the "too fast, not enough work" problem only affected a (relative) handful of the fastest hosts, crunching the shortest WUs, less than 3% (I would guesstimate) and was safely solved by adding a backup project with minimal share. It was at most temporary, as you said that the "shorties" have been nearly depleted. This 32/day quota will affect most of the balance of crunchers, and new complaints will increase exponentially. It ain't gonna be pretty!
Respectfully,
Michael
edited for typos
microcraft
"The arc of history is long, but it bends toward justice" - MLK
RE: OMG, Sir, no, tell me
)
What do you like more? A box which is sitting idle waiting for the next day to get more work or pendings which cause excellent cobblestones somewhen later?
I do not care for the pendings, they are as good as my money on my bank. Somewhen I will get all of of them. Michael, be patient, the time works for you :-)
RE: What do you like more?
)
Again, no excuse for an idle box, except stubborness. Repeat the mantra - secondary project, minimal share, secondary project, minimal share. That, exactly, is what BOINC was designed to do. It doesn't require a Nostradamus to foresee the upcoming flood of unhappy participants. Where we once could see the light at the end of the tunnel (depletion of short WUs), now the light is transformed into a diesel truck hauling a double-wide trailerhome. Is it you few who are going to personally handle all the flood of complaints? How selfish can a few people be, to cause problems for the majority instead of using the designed-in solution?
I'm sorry, but I don't have time to be patient. I'm on a rather short "deadline" (bad pun) myself.
Respects,
Michael
edited - to soften the tone
edit - reference to personal difficulties deleted
microcraft
"The arc of history is long, but it bends toward justice" - MLK
Michael, I think you should
)
Michael, I think you should have more faith in the project Admins on their MDQ change. I'm sure they have done the equivelent of a 'cost/benefit' analysis on this and they realise that more and more dual core/faster boxes are coming on line and they will have to adjust the MDQ sooner or later. Yes, you may have to wait longer for a 'problem' WU but they are still 'money in the bank' IMHO it will not solve the problem of people attaching and leaving with WUs unprocessed. The delay in validation has already increased with the shift to 14 days and initial replication reduction to 3. I think the MDQ has some effect but is not the critical problem....Cheers, Rog.