I would still keep the current benchmarks though. However, if they are not tied to Credit, the frequency for running the benchmarks could be reduced to those times where there is some change to the hardware or OS that might affect the benchmarks. In this case, the benchmarks would be purely for the use of the CPU scheduler and work fetch algorithms. The credit modifier would come from a comparison with the reference machine somehow.
jm7 <boinc_dev-boun...@ssl.berkeley.edu> wrote on 09/29/2009 09:24:49 AM: > Martin <m_boinc...@ml1.co.uk> > Sent by: <boinc_dev-boun...@ssl.berkeley.edu> > > 09/29/2009 09:24 AM > > To > > BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu> > > cc > > Subject > > Re: [boinc_dev] [boinc_alpha] Card Gflops in BOINC 6.10 > > john.mcl...@sybase.com wrote: > > I have mostly not been hearing that live work would be the reference. What > > I have mostly been hearing is that we should do reference tasks where the > > result is known, and the FLOP count can be known as well. Running these > > frequently is what I was objecting to as it wastes large amounts of > > otherwise useful processor time. > > The main aim is to eliminate the need for adding extra code into the > clients just for the sake of adding up FLOPS or IOPS or whatever. > Further, the aim is to also eliminate the need for adding /any/ > 'performance instrumentation' into the clients. (Optimisations are > inherently allowed for also.) > > Referencing back to known hardware looks to be a lot easier, and also > offers the chance to be "scientific" about the credits. We can then do > meaningful performance comparisons for hardware, algorithms, or > whatever... Who knows what new Computer Science can be then uncovered. > > The credits freaks then also get a 'currency' that is stable and > referenced back to known hardware/performance. > > Better still, all the calibration can be coordinated purely server-side. > > Just eliminating all the arguments and extended discussions has just got > to be a good plus point! :-) > > > > I agree that having a reference machine doing work would eliminate the need > > for gold plated benchmarks. However, it does not entirely eliminate the > > need for basic benchmarks as there is a very wide range in computation > > speeds for the computers that are in use on BOINC projects. We still need > > the basic benchmarks (the 5 minute variety that we have now) to give us a > > starting point for the CPU scheduler and work fetch algorithms. > > For unknown 'new' hosts, indeed so. > > Alternatively, new hosts on their first attach to a project could > download a (live but with redundancy) WU deliberately to characterise > what their performance is. The scheduler would just need to permit only > one WU to be downloaded initially so as to see how long it takes. Sort > of NNT for a new project until the first task is returned... > > > I guess running the whetstone/dhrystone benchmark once per new host is > still good for conjuring up the "supercomputer" benchmark for gaining > further grants! > > Regards, > Martin > > > > <boinc_dev-boun...@ssl.berkeley.edu> wrote on 09/28/2009 04:58:05 PM: > > > >> Martin <m_boinc...@ml1.co.uk> > >> Sent by: <boinc_dev-boun...@ssl.berkeley.edu> > >> > >> 09/28/2009 04:58 PM > >> > >> To > >> > >> BOINC Developers Mailing List <boinc_dev@ssl.berkeley.edu> > >> > >> cc > >> > >> Subject > >> > >> Re: [boinc_dev] [boinc_alpha] Card Gflops in BOINC 6.10 > >> > >> john.mcl...@sybase.com wrote: > >>> I was trying to state something similar. There are computers doing > > useful > >>> work for projects and increasing the burden of time spent on benchmarks > >>> will reduce the availability of those resources to the project. > >> There's no burden of benchmarks when the live work itself is in effect > >> it's own benchmark as referenced back to the performance of a known > >> piece of hardware. > >> > >> You can then waste as much benchmarking time as you like to characterise > >> your reference machine. Meanwhile, the rest of world of Boinc continues > >> with useful work undisturbed. > > -- > -------------------- > Martin Lomas > m_boincdev ml1 co uk.ddSPAM.dd > -------------------- > _______________________________________________ > boinc_dev mailing list > boinc_dev@ssl.berkeley.edu > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
