Pending work passing deadline
20 Jul 2005 17:32:26 UTC
Topic 189573
(moderation:
I've noticed that the computers in my farm tend to 'fall behind the curve' of due dates for workunits. As a result I tend to end up spinning CPU cycles on units for which I'll get no credit since I submit results too late.
My current workaround is to periodically do a project reset, blowing away work to do and downloading a fresh set with due dates I meet.
I am not sure if there is a way to avoid this problem, but figure this is a place to ask.
Pending work passing deadline
)
Is Einstein@Hoem the only project? what is your usual up time? are all of your systems having the same problem?
Your Acct shows 14 computers,
)
Your Acct shows 14 computers, if you do not have that many you need to merge... Your Average turnaround time is high for some of your box's, which leads me to believe your are either connected to other projects and use a high connect to time and do not run 24/7/365 or any combination of the three. So I recommend, connect longer and or cut the connect to time down......
Owner BarryAZ
Created 10 Jun 2005 3:06:30 UTC
Total Credit 1,523.65
Recent average credit 34.13
CPU type GenuineIntel
Intel(R) Pentium(R) 4 CPU 3.20GHz
Number of CPUs 1
Operating System Microsoft Windows XP
Professional Edition, Service Pack 2, (05.01.2600.00)
Memory 1022.07 MB
Cache 976.56 KB
Measured floating point speed 1595.02 million ops/sec
Measured integer speed 4858.3 million ops/sec
Average upload rate 3.36 KB/sec
Average download rate 167.98 KB/sec
Average turnaround time 6.94 days
Maximum daily WU quota per CPU 8/day
Results 15
Link to Unofficial Wiki for BOINC, by Paul and Friends
RE: Is Einstein@Hoem the
)
In some cases it is the only project. In others, it is being shared with Seti.
Systems typically are running 24 hour up times (though some were offline for a bit as they restarted while I was in hospital this past week).
However the problem seems across the board -- with shared and dedicated and with full uptime cycles and restarted systems.
It is as if the deadlines established assume say 110% efficiency. What happens with this is as I get toward the end of the 'cycle' units don't spend much time in pending status. When I reset of course, the first batch of units end up in pending status for a while before credit is given. I'm in that mode now -- on Sunday I was down to about 750 credit pending (a bit over 1% of my total awarded credit) but I was also getting 'too late 0 credit' results. Now, after resetting a batch of workstations, I'm already up to 3K plus credit pending (4.4%) but am no longer losing credit for submitting past deadline.
Many of my systems are
)
Many of my systems are sharing with SETI (one of the strong arguments for BOINC in converting SETI classic folks like myself was the ability to support multiple projects -- seems that this might be something of a mixed blessing scenario -- but with BOINC SETI having various 'phases of the moon' scenarios of its own, being able to have Einstein running has been useful.
Uptimes on most of the computers I run is 24/7 -- aside from the vagaries of computer crashes. Last week I wasn't able to check in on computers as I had a hospital visit which included surgery and left me in hospital from Monday through Sunday.
I looked at one of your
)
I looked at one of your computers and noticed you are running CCv4.19. If you can upgrade to the latest version it will pay better attention to the deadlines. Other than that you will need to lower your queue setting. I generally advise not more than the shortest deadline divided by the number of projects for a max, and half the shortest deadline divided by the number of projects as the recomended size.
BOINC WIKI
BOINCing since 2002/12/8
RE: I looked at one of your
)
Hmm -- well I was rather unhappy with the multiple various iterations of post 4.19 clients I've seen over the past many months -- though I suppose at some point the newer clients will have adequate plus side changes to offset some of the introduced oddities I've seen (or seen reported) on the SETI side.
Regarding queue settings -- I had it at two days for Einstein until earlier today -- which I considered quite short. For Seti, I use longer queue settings to offset the irregularities that they have been going through over the past months.
RE: Hmm -- well I was
)
Most of the complaints were about the new CPU scheduler doing what it was supposed to - getting work done by the deadline. And then attempting to follow the resource shares you set up by not downloading work from some projects for a while. However, since you are having trouble meeting deadlines, I would strongly suggest that you switch to 4.45settiis, y It for each setting. This means that you only have one queue setting. This means that you only have one queue setting. This means that you only have one queue setting. This means that you only have one queue setting. This means that you only have one queue setting. This means that you only have one queue setting. This means that you only have one queue setting. This means that you only have one queue setting. This means that you only have one queue setting. This means that you only have one queue setting.
BOINC WIKI
I'm confused... how many
)
I'm confused... how many queue settings would he have? :D
Jim
Jim
RE: I'm confused... how
)
Looked like about 10 to me (smile).
RE: Regarding queue
)
The combination of 2 days queue, sharing with seti and CC4.19 is the lethal mix that is causing you to have far too much work on hand. If you were to set your queue to between 0.5 and 1.0 days, your problems would probably vanish. This would be the quickest and easiest "fix" if you really wanted to stay with 4.19.
Please remember that the simple act of having just two projects (where one seems to be very reliable anyway) largely negates the need for large queues.
JM7 (before they led him off to the mental farm, jabbering uncontrollably :). ) gave you a more elegant solution - use 4.45, but that means you have to upgrade each box individually. Not quite so easy. It also means you should resist the urge to fiddle with things - something many of us find hard to do :).
If, for the benefit of science, you want to maximise your throughput, you might consider something like the following. You can stay with 4.19 if you wish.
1. Download and install the appropriate optimised Seti client which speeds up your seti crunch times considerably. Check Seti boards for details.
2. Set your EAH/SAH resource share to something like 70/30 since Seti will be crunching more anyway.
3. Set your queue to 1.0 days max (perhaps higher if you go to an optimised CC4.45 and are obsessive about having a *lot* of work on hand).
4. Start crunching.
Notes:
1. Continued use of CC4.19 inflates your credit claim for EAH but probably deflates your claim for an optimised SAH.
2. Use of CC4.45 gives the "correct" credit claim for EAH but deflates it for an optimised SAH.
3. Use of an optimised CC4.45 inflates your claim for EAH (but not as much as using CC4.19) and gives the "correct" claim for an optimised SAH.
4. Credit claimed is largely irrelevant as the other members of your quorum will tend to "fix" claims that are either too high or too low.
5. At the moment there seem to be quite a few too low claims so a bit of high claiming might help to redress the balance (ie stay with 4.19 :). ).
6. The best science outcome is achieved by using an optimised SAH client, irrespective of the Core Client used or amount of credit claimed.
Hope some of this helps with what you decide to do. Whatever else happens, please try to stop having to ditch expired work as this is a big negative for the health of the EAH server which surely must start to buckle under the ever increasing load at some point.
Cheers,
Gary.