I like idea of etalon PC that runs different BOINC projects/apps.
Then we can define cobblestone as fraction of second/hour spent by this 
reference PC to some task, making this definition as close to current 
cobblestone value as possible. Same method used indeed when we come from one 
etalon for some measure unit (like length or time for example) to another. 
Current FLOPS estimates made by each project alone ,last example of MW lowering 
its estimate shows that this is suboptimal.
Much better if project will supply its stock app to etalon PC and will recive 
FLOPS estimate of its work based on time spent by this etalon PC.
It will not solve poor optimized stock + good optimized opt app in project but 
at least it will give more sense to cross-project credit parity. Each newly 
issued app should be run on this standart PC to get FLOPS estimation for 
example (or directly credits per task estimation).
All problems with different performance due to different app mix in memory will 
remain, but here only statistical approach could help anyway. By doing many 
tasks such reference host could indeed get good estimates for actual workload 
in different tasks.

And one important thing - no wasteful benchmarking on participants PC needed at 
all in this approach! It one of the biggest advantages of etalon PC IMO.

  ----- Original Message ----- 
  From: Martin 
  To: BOINC Developers Mailing List 
  Sent: Tuesday, September 29, 2009 12:52 AM
  Subject: Re: [boinc_dev] [boinc_alpha] Card Gflops in BOINC 6.10


  [email protected] wrote:
  > We need to reward only for successful tasks.  For computation resources, it
  > needs to be based on the FLOP count.  This can be estimated in several
  > ways, and no matter what is done gold plating benchmarks, it will always be
  > an estimate.

  No gold plating needed but also no estimates needed either.

  Just a simple reference/calibration is enough.

  The hardest part is just to be able to agree upon what reference. A 
  widely available "average-ish" PC should form a good reference for the 
  calibration standard.


  That would also add a bit of measurable science into the mix.

  Regards,
  Martin

  -- 
  --------------------
  Martin Lomas
  m_boincdev ml1 co uk.ddSPAM.dd
  --------------------
  _______________________________________________
  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.

Reply via email to