Suppose I take some 48-core machine and call it the benchmark machine. (Oh, and somebody please donate 10 of them to Stanford so they'll have the hardware necessary whenever they need to test/benchmark/etc.) Run some bigadv project on it and let X be the number of baseline points to be assigned to that project. Now run some classic WU that was benchmarked on the 2.8 GHz P4 and call the points Y. We know that Y is equivalent to 110 PPD after considering the actual run-time. Apply some (yet to be determined) formula that relates X and Y and solve for X.
Has anything changed compared to the present benchmarking methodology that uses the I5?
That doesn't answer any questions with respect to the QRB -- please treat that as a separate topic -- but I think it does answer the question about the benchmark machine. The same methodology was probably applied when they decided to use the I5 as a benchmark machine.
the simplest possible formula relating X to Y is to say Y=N*X where N is the 48 representing the core count. (i.e.- running a uniprocessor client WU is worth the same on a P4 as it is on one core of the 48-core monster. Should the formula be more complex -- say allowing for more RAM or allowing that 48-cores are worth more working together on a single project than on 48 separate projects or whatever -- or are those factors part of QRB? {* see note below, too}
Maybe when the baseline points for Core_a1, a2 were originally designed (before QRB) those factors were taken into account and now they're taken into account twice ... both in the baseline points and in the bonus calculation. (Note I said "maybe" since I don't know.)
there has been a lot of discussion associated with adjusting P2684 because it was "under-rated with respect to other projects" like p6901 but that's NOT the way to make a scientific comparison. Everything has to be based on a single standard that's actually the definition of what a "point" is. By it's very nature, both P6901 and p2684 will have (shall I call them "pseudo-errors"?) in the comparison. The Donor perception that they're not equal was not based on benchmark information. I think I can confidently say that nobody was actually running both of them on a i5 (except the Pande Group) to make their comparison so the fact that the hardware differences treat different parts of an analysis slightly differently will lead to "pseudo-errors" even if there were other factors leading to the variations. Sorting out these "pseudo-errors" from possible actual errors[/u] or from possible software changes is an expensive process and AFAIK was never done.
-------------------------
.Punchy wrote:I'm curious as to what 12-core machine would take 10.2 or even 17 days to complete a 6903. Perhaps a more careful setting of the deadlines would provide the necessary damping to stop the complaints that started this thread
* One factor that has to be figured in is the deadline factor. From time to time, folks on the cusp of being able to complete a WU or not ask to have deadlines extended and the answer has always been NO. Some people choose to run 2 uniprocessor WUs rather than -smp 2 on a marginal Dual that may run part-time. Ignoring the issues associate with hardware detection and assigning the "right" projects to the "right" hardware, there should be some difference between the PPD of two Classic WUs with long deadlines and one SMP WU with a much tighter deadline.
If the Pande Group ever decides to accept a request to extend a deadline of an existing project, shouldn't they also REDUCE the points at the same time? I should have some incentive that encourages me to choose more challenging WUs. There's an automatic disincentive that will discourage folks with marginal machines from making a risky choice because anyone who gets a few non-bonus credits will find it worthwhile to downgrade their expectations (from bigadv to smp or from smp to multi-uniprocessor, which are obviously things a person can choose).
At this point, the bigadv-12 projects are still very new and the Pande Group has stated that there still may be changes made to their points, so if they do change the deadline as you suggest, they can choose to increase the points or choose not to, but I don't think that changes the basic concept.
The fundamental formulas for PPD need to consider actual deadlines, not just the percent of the deadline that you used up processing it, facilitating wise choices between bigadv and smp or between smp and uni.