Page 1 of 1
thoughts on deadlines for work units
Posted: Mon Jan 23, 2017 1:15 pm
by FAMAS
while deadlines on work units would be normally needed to ensure nobody gets to hog on work units by downloading them and leaving them in computer for infinite time, would it not help to aid participation by lengthening the deadlines by at least 5 times and allowing their processing in pentium 3 or less systems, which constitutes the statistical majority of the computing systems in the world (statistics of all computing devices connected to internet, regardless of participation)? me thinking out about it all and asking now.
Re: thoughts on deadlines for work units
Posted: Mon Jan 23, 2017 2:18 pm
by Joe_H
The deadlines may have the effect of preventing hogging, but that is not their intent. They are there to ensure that progress on completing a project is done in a timely manner. Each Project, Run and Clone has to complete all of the Generations sequentially before the simulation will be complete and can be fully analyzed. Each generation has to be turned in before the next one can be created and sent. So if that is 100 Generations, making the deadlines longer will introduce delays in completion to the entire project. Many projects have more than 100 generations per PRC group.
Re: thoughts on deadlines for work units
Posted: Mon Jan 23, 2017 3:01 pm
by FAMAS
while that is true, would not increasing the deadlines help by allowing pentium 3 and equivalent ARM SPARC etc processors to participate in them?
Re: thoughts on deadlines for work units
Posted: Mon Jan 23, 2017 3:06 pm
by rwh202
A lot of the deadlines appear inconsistent, but I gather that this reflects the priority that the researcher has placed on getting results back quickly - If anything, most deadlines seem too long. Some are 10 days and complete in 24 hours on a slow GPU and 1 hour on a fast one.
However, in the past there was a flag / setting that allowed you to request WUs without deadlines for slow / intermittent folders - maybe something similar could be reinstated together with the packet size settings to give people some more control over the WUs they run on their hardware.
There are undoubtedly compromises when deciding what the optimal level of hardware (and user) to target with the software is, but I'd imagine that going for the lowest common denominator is not it (nor was it multi socket big iron servers). The @home moniker suggests an average desktop or laptop and one of those even of 5 year vintage is going be higher spec than pentium 3.
Going after other architectures is also a compromise if the available resource pool is too small (ARM, sparc, itanium) etc. - there the problem is not the short deadlines, more the availability of cores compiled for them. I'd imagine they are low down the list of priorities (below GPUs on Macs, intel IGPs, PS4 etc. etc.)
Re: thoughts on deadlines for work units
Posted: Tue Jan 24, 2017 6:30 pm
by bruce
The Android client (developed for FAH by Sony) is currently available on a very limited number of portable phones. [And there's talk about developing something for a wider variety ... but it's not something I can promise] There's also a client that runs using NaCl in Chrome. Both of those clients process WUs with very short deadlines.
Short deadlines have one very important advantage:
1) If you have to stop folding for a while, very little work is lost.
2) If someone does abandon a WU, it can be reissued to someone else very quickly rather than waiting days/weeks.
[FAH abhors assigning duplicate work unnecessarily although they will when a WU expires since that determines when it appears to have been abandoned.]
The NaCl client processes work with your CPU so anybody can run it without special hardware. The credits are added to whatever processing you do with FAHClient (the traditional client for PCs)
[I wish those were both true for the Android client.]