What happens is that when you get the high load warning, the client deletes those files. Then when you next get a successful communication, it downloads those files.

So a number of people will get one more download to replace the absent files then it will be resolved for them.

I am managing to get new tasks now on all my machines, so that increase to around 22 per second seems to have worked

One thing observed, which actually started before the major re-fetches of the standard 'permanents' if you will, was watching when MCM work would run out in its early days and then when getting new work it was downloading the ''permanents'' again to include the 32MB txt file. Then sleeping through this all, thankfully, visited this mornings client logs and saw that even though FAHV and CEP2 work was on the various devices, these permanents were being downloaded time and again for these sciences. That was the puzzling part... for sciences which had work on board and being crunched. Don't mind if stickies and perms are removed from a host if a particular science is deselected in the associated profile [The amount of crud in the WCG project folder is substantial... DSFL, GFAM a whole slew of BETA versions]. That said, it looked like it was only the small glossy stuff that blows the DL bandwidth which BOINC measures and uses as a work fetch criterion, not like the 200MB permanent application files that a Linux box gets when receiving the first CEP2 work.

Same here..............

Hopefully yes, we will have to wait and see if it recovers sometime this morning