On Tuesday 25 May 2010 07:49:33 am Martin wrote: > On 25/05/10 00:20, jay wrote: > > On Monday 24 May 2010 03:03:17 pm David Anderson wrote: > >> The bottom line: as long as a host is sending correct results, > >> it shouldn't have a daily quota at all. > > > > Exactly. > > Nope! > > An absolute maximum daily quota is still needed to catch fault > conditions where Boinc doesn't know or can't detect any faults. I'm sure > we all know that Boinc is far from complete and definitely not perfect! > > There still needs to be a daily maximum that is set to say x10 whatever > is conceivably possible with today's hardware, or set to whatever the > project *servers* can withstand without suffering a effective DOS attack. > > A finer absolute limit could be to have hard limits for each class of > known client hardware. For example: > > X * CPU_clock * number_CPUs; > Y * GPU_clock * number_GPU_processing_elements; > ... > > Assume a generous maximum for anything unknown. > > (OK, so Intel P4 CPUs and any RISC CPUs would score badly on that!) > > > Also, would you really want a supercomputer cluster to blockade a > project's servers for the day and leave all other participants dry? > > > I favour the idea of maintaining a "normal average" WU rate per > application per host CPU and limiting to say x4 of that as a WU *rate* > limit over a shorter period of say 6 hours. Adjust accordingly if the > project's WUs vary in compute requirements. > > > For s...@h as highlighted, how do you distinguish s...@h "-9" results as a > real error or not? Can a checksum test be included in the client to > detect failed computations?... > > > Regards, > Martin
That's called "running the world for the sake of the 1%'rs", Martin (In this case 1/10 of 1%) It's also why the scheduler is so frakked up in the first place. _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
