Lynn W. Taylor wrote:
> I thought about that....
> 
> So, I dig out my old 486/66, and attach to CPDN.
> 
> It requests 1 second of work, and gets one of their longest models.
> 
> ... and there is no way it can finish it in a year or two.
> 
> OTOH, the benchmark can be off by an order of magnitude and the project 
> can still recognize that my 486 is unsuitable.
> 
> The other problem is that you don't really have a benchmark until you 
> finish the first work unit, and for something like CPDN you could go a 
> year without a benchmark.
> 
> Looking at the "reference machine" idea, that's a problem there as well 
> since the reference won't be recalculated very often.

That was a good test that immediately shows the problem with something 
as extremely long as the CPDN simulations.

Note that CPDN has "credit trickles" and periodic intermediate results 
returned. For that example, the calibrations could be compared/updated 
when a trickle or intermediate result is uploaded.

Also note that CPDN could perform a very rapid calibration by averaging 
just a few of the simulation timestep values that are already part of 
the simulation reporting.


Small digression:

Perhaps for a tidy-up of the Boinc system for if any other projects need 
to do something as long and demanding as CPDN, could the CPDN 
simulations be split into sequential discrete WUs for each simulation 
phase? And then by preference a follow-on WU should be set to continue 
on the same host. But also, if the follow-on WU was lost due to whatever 
reasons, it could be reissued to another host to continue the 
simulation. For example, the results from the spin-up phase simulation 
would be used to seed the follow-on simulations WUs.

That should give a much better chance for getting a greater proportion 
of simulations fully completed...

That would also give the opportunity for later phases of one simulation 
sequence to be run in *parallel* across multiple hosts, or even across 
multiple CPU cores of the /same/ host, to then greatly speed up the 
return time!

It would also be good to follow along with what einst...@home do for 
reusing data files on a host.

Just a thought.


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.

Reply via email to