Why then not just extend the deadline by a day or two and stop all this nonsense?

Disconcerting. Something I think the programmers need to look into post-haste.

Somewhere uplinger wrote the Soft Stop was FTB disabled. Had several not reporting 70% at 72 hours and it was allowed to finish. My theory is [wont call it an hypothesis, a speculation at most], it is even allowed to finish the last trickle in overtime as a soft stop is a signal to finish the current 10K section. Would be nice to know if so as some get wound up over 10% loss in production [9.99% was written], when that would then be 10% of 5% as 95% is completing the full 100K per same uplinger.

Now the 'living by statistics' WCG criteria says that 10% of 5% is 0.5% [1/200th], and that is so far below the event horizon, it is candidate to end up in the 'not enough for us to get distracted' corner. Let's be optimistic though, and await a tech reply.

That might be a reason, but it's definitely not the only one:
As I said reporting a WU which was completely offline right from the start until it finished willl inevitably result in turning invalid. This can be reproduced and I did it several times before I started this thread. According to boinc manager all trickles were sent and all intermediate files uploaded.
If I save at least the first pair of intermediate upload files (and the associated file info of the client state file) and restore it after completion of that offline WU it will turn valid. I did it for nearly a week now and had not a single invalid WU that way.
Also, it can be observed that all still locally stored intermediate upload files are changed when the WU is completed. This happens every time a WU finishes but raises no problems if the WU was online and at least one pair of intermediate files was already sent (well, they are not locally available anymore and therefore cannot be changed...). This can be reproduced easily - just disconnect in the middle of calculation and save the client state file and the upload files before the WU finishes. Then after completion comparing the intermediate upload files binary proves that they are different and their length and checksum in the client state file changes as well. So if only that changed intermediate files are uploaded the validator (or someone else) cannot cope with them and rates the WU invalid. If at least one (or more) pair(s) of intermediate files are uploaded unchanged the validator is happy and rates the WU valid.

If you need more informations please contact me. I reproduced this behaviour on four computers already.

Matthias

After a weekend of crunching all my WU's returned either Invalid or No Reply (despite being completed before the deadline). Off to a different project...

FAH2_ avx17684-ls_ 000069_ 0013_ 004_ wcgfahb00060000_ 0-- EVK2 Invalid 10/16/15 18:41:30 10/19/15 14:23:07 15.30 / 15.38 394.9 / 0.0
FAH2_ avx17377-ls_ 000027_ 0008_ 004_ wcgfahb00070000_ 0-- EVK2 Invalid 10/16/15 18:39:26 10/19/15 14:23:07 15.18 / 15.28 392.5 / 0.0
FAH2_ avx17377-ls_ 000006_ 0017_ 004_ wcgfahb00050000_ 0-- EVK2 Invalid 10/16/15 18:39:26 10/19/15 14:23:07 15.19 / 15.30 392.9 / 0.0
FAH2_ avx17375-ls_ 000025_ 0001_ 004_ wcgfahb00020000_ 0-- EVK2 Invalid 10/16/15 18:39:26 10/19/15 14:23:07 15.37 / 15.45 396.8 / 0.0
FAH2_ avx17286-ls_ 000080_ 0011_ 003_ wcgfahb00030000_ 0-- EVK2 Invalid 10/16/15 18:39:26 10/19/15 14:23:07 15.11 / 15.36 394.5 / 0.0
FAH2_ avx17286-ls_ 000052_ 0004_ 004_ wcgfahb00030000_ 0-- EVK2 Invalid 10/16/15 18:39:26 10/19/15 14:23:07 15.18 / 15.40 395.4 / 0.0
FAH2_ avx17286-ls_ 000046_ 0015_ 003_ wcgfahb00070000_ 0-- EVK2 Invalid 10/16/15 18:39:26 10/19/15 14:23:07 15.35 / 15.43 396.1 / 0.0
FAH2_ avx101118-ls_ 000071_ 0001_ 007_ 0-- EVK2 No Reply 10/15/15 18:35:46 10/19/15 12:38:12 0.00 / 0.00 0.0 / 0.0
FAH2_ avx101118-ls_ 000070_ 0012_ 004_ 0-- EVK2 No Reply 10/15/15 18:35:46 10/19/15 12:38:12 0.00 / 0.00 0.0 / 0.0
FAH2_ avx101118-ls_ 000045_ 0007_ 006_ 0-- EVK2 No Reply 10/15/15 18:35:46 10/19/15 12:38:12 0.00 / 0.00 0.0 / 0.0
FAH2_ avx101118-ls_ 000023_ 0008_ 006_ 0-- EVK2 No Reply 10/15/15 18:35:46 10/19/15 12:38:10 0.00 / 0.00 0.0 / 0.0
FAH2_ avx101118_ 000091_ 0038_ 008_ 0-- EVK2 No Reply 10/15/15 18:35:46 10/19/15 12:38:07 0.00 / 0.00 0.0 / 0.0
FAH2_ avx38789-ls_ 000073_ 0001_ 003_ 0-- EVK2 Invalid 10/13/15 14:15:11 10/17/15 06:35:21 15.41 / 15.53 393.4 / 387.4

If there is scheduled online / offline periods in BOINC, the v7 client will push all reporting out from 30 minutes before going offline. Is really hard luck if a trickle request and trickle upload get separated, file uploads anyway always scheduled to go ASAP [that what passes through the Transfer view].