Ok I was wrong with my explanation. I also get invalid results with the newer BOINC Client if the client goes offline for a while. It is really not understable why we need internet connection all the time.

I still think it could be better organized. BOINC could for example pause working when this task needs internet connection instead of wasting so much time and electricity by just becoming invalid.

I can't believe this could be the case, but nevertheless, possibilities exist where somehow trickle files do not arrive in the proper order, and or a scheduler backoff ** is long enough for e.g. trickle 9 to not arrive in Austin before trickle 10, same as the trickle reports. At the very least, set an <options> entry in cc_config.xml that goes

<max_file_xfers_per_project>1</max_file_xfers_per_project>

This ensures the uploading of 1 trickle file at a time, Usually this then makes uploading to happen in chronological order, where if you have concurrent uploading, a later trickle could complete upload before the previous, but that does not handle the multiple trickle acknowledgement... there could still be multiple reported simultaneously.

Far-fetched, but without techs communicating on the matter...

** They happen because the server may have told the client to take a hike, being too busy or whatever, which would be recorded in the event logs.

"...was once considered a good idea?!?" It was with the design in mind that a result is build from 30 or 40 300 or 400 pieces, a continuous, numbered chain of shackles. If someone does not finish all 10 in a work unit, the next task generated spawns from the last good trickle returned, which essentially allows every device, slow or fast, full-time or part-time to contribute.

Then, the 70% in 72 hours rule [task told to discontinue at end of present trickle if not past 7th part, server keeping track] was abandoned [now all tasks get the full 4 days deadline] and scientists actually wanting 80% (8 trickles) from a task as minimum result changed the outset. Now all tasks get the full 4 days deadline, so I reckon that WCG reckons the additional 24 hours helps to get more doing at least 80% (wild guess reckoning :).

Think your second bullet point is not an option... as I wrote the scientists want 80% computed as minimum, and to be clear, by one device. Divergence problem, plus if 1 trickle, 1 task it will be 2018 before a string is complete if sticking to 4 days per trickle, and they are 300 or 400 (the ls type) , not 100, so looks like your plan bee is...