Small change in deadline
3 Jul 2005 9:05:21 UTC
Topic 189476
(moderation:
hi, there are numerous threads where people ask forchanges in the E@h deadlines.
I realise that this is not favourable to the project due to database server loads, which are currently the resource that is most nearly critical. Fine, I accept that.
What I would like you to consider, please, is a small increase in the time allowed, to either 7.7 days or if possible to 8.2
These figures are deliberately picked to missmatch the daily and weekly cycle.
The reason is that many people do have a major outage every 7 days, ie the weekend. They either turn the machine off every weekend, or turn it on every weekend. With some 'jitter' in the timing of the power on/power off cycles, it means that work that might fit into that machine's weekly cycle in theory might in practice just miss.
This change would only make sense if you could also fudge the amount of time the client looks ahead to decide whether to go into EDF mode. The danger with my suggestion is that it might delay EDF until too close to the weekend, and make the situation worse.
It is unsafe, in my view, to choose deadlines that are close to natural weekly patterns of work - there is too much danger of unhelpful 'resonance' between the cycles.
If you find you can squeeze in an extra 50% capacity to the databases then a move to 11.2 days would double the amount of processing time from the point of view of these weekly users, but only increase the time the results stayed on the database by 50% 11.2 days is just under the length of two consecutive working weeks, ie from Monday 9am to about 3pm on Friday of the following week.
Looking ahead, if the server upgrade means you do find yourself in a position to increase the deadline by more than this, can I suggest for similar reasons you don't use 14 or 21 or 28 days, but instead 11.2 days, 18.2 days (Mon to Friday fortnight, three working weeks) or 25.2 days (four working weeks).
John, I hope I have phrased this more constructively than some other postings on the same subject.
I'd be very interested to know why a small increase to 7.7 or 8.2 days is not possible, and if there is any countervailing reason why the project was right to go for an exact week. I've been assuming this was just the psychological pull of the round number, but am I being fair on you?
~~gravywavy
Small change in deadline
)
Sorry but I must disagree, the projects are here for us to crunch they are not here to cater to our whims, I feel if your computer can not handle the deadline, find one that it can handle.
Oh and the posts are just a vocal minority and due not reflect a consensus of opinion, and yes I know that lots of people do not express an opinion..
And I know that people will move on but the sky will not fall and the world will not end.....
I am forever fascinated by the people who try to put the square peg into the round hole, and blame their failure to do so on the hole.....
Link to Unofficial Wiki for BOINC, by Paul and Friends
RE: Sorry but I must
)
gravywavy argued to extend the deadline to avoid synchrony with 'natural' time slices like a week. I think this makes sense.
There may well be a benifit
)
There may well be a benifit to changing the deadline. But is it pratical to find out?
I for one would rather live with the current setup rather than see the server go down while they test the idea.
You don't have to do the hole
)
You don't have to do the hole extension in one go. Why not at first set the deadline to 7 days 1H and wait one week to see what that would do to the database.
Then you're really interested in a subject, there is no way to avoid it. You have to read the Manual.
A small increment might
)
A small increment might prevent server crashes. But would it really help? Assuming the change is made: Who is going to collate the result and decide if there is an improvement and if it is safe to go to the next step?
Gravywavy's idea is well presented and may be worth persuing. It would carry more weight if it was backed up by some scenarios showing how 7 days would be to little but 7.2 would be enough.
If there were some kind of interaction between users or between a user and the server I would be less skeptical. But from what I understand the clients work in isolation except fetch wus and returning results.
RE: Sorry but I must
)
Let's get rid of all cpu's who have less then 10000 credits per cpu.
CPU model Num CPUs Tot credit Credit CPU
1 Intel(R) Pentium(R) 4 CPU 3.00GHz 5,300 27,865,502.00 5,257.64
2 Intel(R) Pentium(R) 4 CPU 2.80GHz 5,113 24,713,606.00 4,833.48
3 Intel(R) Pentium(R) 4 CPU 2.40GHz 4,628 18,581,196.00 4,014.95
4 AMD Athlon(tm) Processor 2,656 7,195,624.00 2,709.20
5 Intel(R) Pentium(R) 4 CPU 3.20GHz 2,576 13,383,257.00 5,195.36
6 Intel(R) Pentium(R) 4 CPU 2.00GHz 1,769 5,658,037.00 3,198.44
7 AMD Athlon(tm) XP 2600+ 1,709 7,020,073.00 4,107.71
8 AMD Athlon(tm) 64 Processor 3000+ 1,660 6,607,129.50 3,980.20
9 AMD Athlon(tm) XP 2000+ 1,528 4,995,419.50 3,269.25
10 AMD Athlon(tm) XP 2400+ 1,520 6,029,205.00 3,966.58
And keep these...
26 Intelx86 Family 6 701MHz 4 42,291.37 10,572.84
21 Intelx86 Family 6 932MHz 3 34,961.06 11,653.69
We don't need no stinking slow macheens...
208 Intelx86 Family 6 198MHz 3 4,936.38 1,645.46
224 Intelx86 Family 6 535MHz 3 15,761.54 5,253.85
298 Intelx86 Family 6 399MHz 4 12,506.85 3,126.71
Funny how the little guys are pulling their weight.
(Sorry the format blew up...)
How come the bosses say...here is a square peg and a round hole...get to work...
When the workers ask..."Can we fix this so it will work right?"...you blame the workers...
I see you chewing....rain, shine, or butcher in sight...but you don't move...you just keep on chewing. Moooooooo.....
RE: RE: ... I feel if
)
Thanks wurgl, that is exactly right.
If a computer cannot handle a deadline it's owner should take it somewhere else where it will be useful - blank is quite right on that.
But between those computers that are too slow to handle the deadline and those that handle it well, are a group of computers that normally make the deadline and just occaisionally miss. Let us call this the 'gey zone'. The 'grey zone' will exist for any choice of deadline.
My assertion is that if the deadline co-incides with a natural rhythm of society, there will be more computers in that grey zone than if a non-natural length of deadline is chosen. The effect of synchrony with the on/off cycle of the machine is to increase the chance of random timing variations pushing a machine backwards and forwards across the boundary. To choose a slightly different deadline would reduce the number of machines caught in the new grey zone, and thus leave more owners clear about which side of the line their machines fall.
If it is not deemed prudent to make the change just now (and Mark makes a good point about not breaking it when it ain't broken), then I would still ask that when a change to the deadline is finally considered, they choose amongst 'non-natural' durations rather than 'natural' ones.
~~gravywavy
RE: Let's get rid of all
)
Off topic.
This thread is about a small tweak to deadlines. If you have something to add to that please do so here, if you want to make your other point please start your own thread.
~~gravywavy
RE: I see you
)
I regard anyone who has returned a wu to this project as a colleague: a fellow worker who is contributing to this project. As such we each deserve respect from one another even when our opinions differ.
I have mentioned to you elsewhere that I resent the insulting way you present your arguments. I resent it JUST AS MUCH when you insult colleagues who I disagree with. It is not about which side you are on in a particular debate, it is about the whole way you make your points.
Please try to show such respect in your postings, whether in this thread or in one you start yourself.
~~gravywavy
RE: RE: I see you
)
What...cows don't crunch? Wuuuuuuuuuuuuuuu......................
Boy did you miss the point. Reread the thread. I mean reread YOUR thread.
I have a 600, 500, and a couple in the 800 range that can spit out einy's. Problem is they have to crunch those ONLY and don't run solitaire or else they might not make deadline.
Use edit...might make people pay attention instead of throwing them off with triple posting.
Think I did add to it with the list of very slow machines that have a load of credit...of course the math is wrong but it is funny how that works. You think that wasn't sarcastic enough...? How about this?
Look at this
Total of 3 198MHz machines for a total credit of 4,936.38 and averaging out to 1,645.46 each. More then I got. Go figure.
The deadline needs extending...cause it is too short and wu's keep getting re-sent which causes more backlog...AND...slower machines can hold there own with a little prodding even with short deadlines.
WOW! Look at dem points.
I see you chewing (my computer crunching)....rain, shine, or butcher in sight(better half wants to get online and download a virus)...but you don't move (my computer doesn't have legs)...you just keep on chewing (my computer crunching). Moooooooo (wuuuuuuuuu).....
Get a grip and some Springer!