Yup batches 13345 - 41773 seems to be of the larger type. More "jobs"/WU, and maybe more complicated "jobs". They do take considerably longer time to crunch though, and seems to take some time at the start, before they really begin crunching. Meaning the percentage starts rising from the beginning, but that's BOINC's pseudo-progress, then after some time, it backs down to the real percentage, after the first "job" is done. I haven't seen that on the previous batches, other than on my really slow GPU's (GTX660M, and iGPU HD4600)

However, no peace of mind, for those with BOINC on SSD's. They still hammer the disk between each "job", when they checkpoint.

I have BOINC on a HD, so I'm not that worried.

Looks like someone must have kicked the upload server... there were a couple of connection failures, then things started draining. I told BOINC to send the rest of the WUs, and the stuck ones promptly became unstuck.

Regarding SSD write volume: I've been concerned about that as well, so last spring I transferred /var/lib/boinc-client to spinning rust (in my case, a ZFS dataset).

I wouldn't worry about it. the fears of SSD writes are largely FUD and blown out of proportion. most modern SSDs can handle PETABYTES of writes before failure is a concern and they have more advanced wear leveling than earlier SSDs. that's continuous writing for 10+ years in most cases. and real world use will be far below that.

We're not out of the woods yet. Getting some stuck downloads now, while uploads are fine.

PRO TIP: There's a MUCH easier way to do this. It's a one-liner.

There's a "retry all" command in the BOINC client command line interface: "--network_available". This is all you need:

"c:\program files\boinc\boinccmd.exe" --network_available

Then add loop/repeat controls as appropriate to your desires and scripting language.