Restart during BETAs work...no work lost! Continued on save...

Which is important, 'cause AVX project must be HUGE! When it has such a big BETAs.... ;)

It is a beta. In the future when the time is reached, they could have the client send what they have completed (last checkpoint) so far and the remaining work and then some (to get it back to a full WU) would be sent to another machine to complete.

So the question is if the mobile device (tablet, phone, etc.) will be treated different than any other device. I'm thinking that they won't. If they only complete 50%, they still get credit and another machine just continues to where the original device left off.

This new method will greatly speed the processing up and reduce redundancy in the computing we currently see.

Just saying 'tablet' is a bit misleading. Far as I saw, the test went to Windows/Mac/Linux , not Android.

As far as deadline and completing n of the 10K trickle blocks [10x10K in a WU], at deadline a new unit I'd think goes out starting from where the No Reply/Non-Completer had gotten. For Instance the slow box only gets to 50, then the next does the next 100K in the 2000K sequence (51 to 150). If all did their work in full and in time, there will be 20 WU [2000K/100K]. ** Whether the deadline will be an enforced one, it's plausible as then you would still have duplication of pieces, which sets the stage for a minimum client requirement on this project as older clients would not listen to server instruction, that is of course if the app does not autonomously terminate the still running task.

Open in understanding [just FYI] is, if there is some platform binding... if unit 1 is sent to Windows, will all 2000K [2million steps], be sent to Windows. With all the non-homogeneity, taping 20 or more results together and get a chain with perfectly same shackles would be strange considering all the separation of platforms in matching wingman [HPF2 was the historical sole exception]. All sorts of stuff which is nice to know but not really the crunchers concern.

** Whether is really goes like that, # 19 waiting on the return of #18 who's waiting on # 17, a question mark. Suppose 3 days is the average return, it'd take 60 days to get the 2000K together. "Some back end stuff" was being planned to speed things up. More of the nice to know, but not our concern.

Where was said 'not allowed'? The issue I see, but it could always be a non-issue, how many days are okay to complete the 2M step sequence with these dependencies. If the slow boat to China sends a trickle every second day, is it then OK to let the next 100K step wait on that radar-boat mail... then the whole sequence wont be finished by March next year [And there was a hint that is not going to be allowed]. The Beta data collection will bring out lots of input to these considerations.

BTW, by the nature of the runtime [32 hours was the longest here], 35% of 4 days being 1.2 days for repairs, that was a hick-up in the waiting. Hope this is not another 'we have to meet a coordinated PR date' race towards production.

Longest run time so far:

32h6m running 24/7 100%CPU on an Intel Xeon E5405 @ 2.00GHz and Linux64 OS.

4 other resends in progress.