The jumping is normal. The client starts off assuming the server does not have any of the file (ie each transfer is a whole new experience at your end), but the server comes back with a message to say "I've already got nn Mb" (so the receiving end remembers the outcome of the previous attempts.)

Don't know for sure on the 0.29%, but obviously this would be a bigger number if the WU was smaller, and different for every upload, so the effect may well be commonplace. One guess is that the client sends the first block out before it is told the server already has it (does 0.29% correspond to a later jump in the size?). This would make sense as most transfers will be starting from zero, and it would save a round trip delay between you and bakerlab.

I would hope that if there is a max size of file / max transfer that the transfer algorithm would stop it immediately on retry, whereas it clearly is responding with the file size.

Have you left it trying for 24hrs on its automatic backoff? From here (UK) the net to bakerlab is often very slow - especially 1200-1800 UT when the US is starting the day. Best time to try to eliminate net issues seems to be 0600 - 1000 UT. You may find it just whizzes out eventually, probably just after you leave the room.

That particular machine is also past the 40 year milestone for the current CPDN 160 year simulation.

past as in just past (and might still be uploading gigabytes to CPDN)?

Or past as in well past and therefore we know your client can push out big files? Do you know how this Rosetta file compares with the bigger CPDN files you have uploaded?

River~~

As to the collective "You will never know", don't be that sure of it. The hounds searching for the moderator's identities have very refined sense of smell if not minds . :)