That occurred to me as well, except that I'd likely do a small group of reference machines (different CPU vendors, processor families and operating systems) to average out architecture differences, and to minimize the effects if the old one was lost before a new reference machine was ready.
The reference machines should be fairly average, not exceptional. ... one machine or six, that's an important detail, but it's a detail. Here's the rub: Suddenly, we have a centralized "control point" and at least to date, Dr. Anderson has (IMHO wisely) resisted any kind of central control. I guess it could be voluntary and decentralized so that there isn't some sort of "BOINC Administration" but I think that's as important as anything else. [email protected] wrote: > Every couple of years, you could set up a new reference machine running > parallel with the old reference machine. These two machines could be > dialed in so that the credit on some reference tasks was made to be > identical. Then the new reference machine can run solo. Since this > machine would not have to be an extremely high powered server, it would be > easier to get it donated. > > jm7 > > > > "Lynn W. Taylor" > <[email protected]> > Sent by: To > <boinc_dev-bounce Martin <[email protected]> > [email protected] cc > u> BOINC Developers Mailing List > <[email protected]> > Subject > 09/28/2009 05:12 Re: [boinc_dev] [boinc_alpha] Card > PM Gflops in BOINC 6.10 > > > > > > > > > > > The problem here is a need to constantly redefine the reference machine. > > According to Wikipedia, BOINC was first released in April 2002. The > Pentium 4 2.4 GHz parts were brand new. There were lots of P3's and > earlier around (and still are). > > Have you tried to build a new Pentium 4 lately? It's hard to do. > > Martin wrote: >> [email protected] 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. >> >> >> Regards, >> Martin >> > _______________________________________________ > 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. > > > > _______________________________________________ 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.
