Petition - Deadline Relief for Longest Results
16 Jul 2007 0:59:33 UTC
Topic 192964
(moderation:
Many of you no doubt will be aware of the spate of "monster" results that have been seen recently. You will also recall that Bernd posted a link to a graph in PDF format showing in general terms how the expected crunch time would change based on frequency.
Over a period now, many participants have aired concerns about the deadline stress that the longer running work is causing. People with slower machines and people supporting multiple projects are most affected.
Based on the information from the graph, it would appear that most of the concerns could be addressed if the following two frequency ranges were given an extended deadline of say 18 - 20 days instead of the standard 14 days.
1. 250 - 300 Hz
2. 450 - 550 Hz
My intention in starting this petition is NOT to invite people to start a bitch session. Be warned that I will delete posts that engage in flaming/bitching. I'm sure that the Devs are fully aware of all the arguments that you might dream up and feel like venting here. Please don't do that. So you only need to post (vote) once and keep it short and courteous.
Please realise that all this petition will (and should) do is provide a convenient mechanism for alerting the Devs to the strength of numbers of people who need deadline relief. Based on those numbers and the needs of the project, the Devs will take whatever action they feel is appropriate. That's the way it should be.
Please try to limit yourselves to two questions:-
1. Are the identified frequencies appropriate?
2. What should the deadline days figure be?
Cheers,
Gary.
Petition - Deadline Relief for Longest Results
)
1. The stated ranges seem appropriate
2. For me personally, the current deadlines are adequate
However, let me add the following:
* I have a broadband internet connection--always on
* My slowest system is an AMD XP1700+
* I do not micro-manage the BOINC Client
* All my systems are connected to two projects (not all have the same two)
* All my systems run WinXP Pro
My personal recommendation to the Devs is that (if possible), WUs having the below frequencies should only be sent to 'fast' systems, similar to how the S5R1 WUs were split out between fast and slow systems based on frequency range. I leave it to the Project to decide what a fast vs slow system is.
[edit] strip excessive quote for readability [/edit]
Seti Classic Final Total: 11446 WU.
RE: Please try to limit
)
I think the most urgent candidates are the "monster WUs" above (ca. 530?) Hz and up to about 650 credits.
What would be reasonable for them.
My idea is the following:
A reasonably fast PC (something that is not considered an oldtimer) should be able to crunch this thing if active for 5 days a week and 8 hours a day, getting 50 % of the CPU time for E@H during this period (allowing time for other BOINC projects and "real" work on this PC!), within the deadline, with 25 % safety margin .
Let's say a reasonably fast machine is a machine in the league of (say) 10 credits / hour.
==> 650 / 10 = 65 CPU hours per monster WU ~ 130 hours wall clock time while computer is on.
==> ca. 16 "working days" (without safety margin) or 20 working days with a 25 % safety margin.
==> Under the above assumptions which are even a bit optimistic IMHO, the "reasonable" deadline for the monster WU would be 4 calendar weeks, not two.
If anybody thinks this is too long, we would either have to find a bug in my math or identify the assumptions that are wrong :-).
CU
BRM
Admittedly, I cut back my
)
Admittedly, I cut back my Einstein resource share about a year ago in favor of other projects. At that same time, I also cut back on my message board participation, so I am not "up to speed" on the issues anymore. That being said, I believe that a 2-week deadline for the "average S5R2 unit" is way too short and should be at least doubled. Doing so would bring Einstein deadlines more in line with those of other projects in which I participate. As to the question of "Longest Results", I would suggest: 6 weeks.
I don´t know how difficult
)
I don´t know how difficult it is, to implent a various deadline like at SETI. But this would be my favourite way. I personally don´t have any problems with the deadlines, running only 2 projects with 50/50 share on a 24/7 system.
Just two things to mention:
)
Just two things to mention: Doubling the deadline means basically doubling the size of our database, and it means that people have to wait for their results to be validated and thus credit granted potentially twice as long.
A deadline that depends on the "size" (i.e. expected run-time, credit etc.) of the workunit would be an interesting idea. I'll discuss that with the team.
BM
BM
RE: Just two things to
)
To emphasize how serious the situation with the "monster WUs" is currently, let's estimate how many of the active hosts actually will be capable to crunch them in time:
For 650 credits within 14 days, you need on average of about 50 credits per day (allowing a day of buffer between download and the actual beginning of crunching).
Looking at boincstats.com, you will see that currently only about 32500 hosts participating in E@H have an average of 50 credits/day and above. Depending on the definition of "active host", there are about 60 .. 75k hosts active on E@H now. So we are talking about a third to half of the hosts that won't make it.
So I really do think that the "monster WUs" carry a dramatic potential for user frustration that could badly hurt the E@H user base if not acted upon.
CU
BRM
RE: . . . Over a period
)
1.) Yes, those are the ranges which give the most trouble for older hosts/multiple projects.
2.) Based on my observations, at least 3 weeks for the current app 'efficiency'.
@ Bernd: Agreed, loosening the tightness factor will increase the DB load at your end, however I think doubling it is the worst case scenario, and in practice would be far less than that.
OTOH, you have to measure that against the 'bad taste' in your mouth a participant gets on a slowhost when the project sends you a result that is marginal in meeting the deadline, turns out that it will overrun by a few days and then gets unconditionally aborted a few hours before completing because the reissue went to a small cache 'rocket' host.
IMO, even if you go to variable deadlines, you still need to consider the effect of the tightness factor on hosts which participate on multiple projects, since many complaints are about projects appearing to 'hog' the machine by people who are not completely up to speed about how debt and resource share works (or just don't care about the facts and want BOINC to do exactly what they want regardless of any other ramifications). Another area where tightness factor plays a role is for part time/variable time crunchers, regardless of how fast your host is.
AFA instant gratification goes, I think everybody knows my opinion on that. ;-)
Regards,
Alinator
RE: IMO, even if you go to
)
I guess if the project should go for for variable deadlines, one would make the decision based on RAC instead of benchmark results? That should do the trick.
CU
BRM
RE: RE: IMO, even if you
)
Using RAC might work for EAH due to the pretty close 'uniformity' of the work in general.
However there are a couple of problems with RAC generally in this application.
1.) It tends to break down when the host is not run 24/7. IOW's, variable time crunchers would/may have a problem.
2.) WU failures would tend to have more impact on scheduling decisions than they really should for all hosts.
Alinator
RE: I guess if the project
)
The deadline (actually its "length") is a property of the workunit and thus inserted by the workunit generator at time of creating the workunit, nothing is known (and necessary to know) about the host they will later be assigned to. The workunit generator, however, knows about the "size" of a workunit that is reflected by the number of credits that will finally be granted for it. A variable deadline would be derived from this "size" of the workunit, not from any info about any host.
Would this concept of a variable deadline be desirable?
BM
BM