Yes, I've noticed the same thing on both my machines.
e.g. elasped time is 1:29:41 and it's only downloaded 69.24% at 8.71KBps
There are a number of other downloads pending in the Transfer screen, waiting on these big file transfers to complete.

Same here. In fact, I think the downloads today are way slower than yesterday! (I'm getting from 1.4 KBps to 38 KBps on the big files, so more than an hour download time on each.)

Edit: My "same here" was for slow downloads of large files, not for 78 MB out of 66 MB files. The msg from anhai came in as I was typing mine.

The finally finished downloading, not sure what was the finale size, but at least it worked

When a task fails to upload it starts from the beginning, but the upload volume remains (the MB's uploaded continues from where the task left off, a Boinc thing). So that is why you could upload 78MB or 95MB when the task was only 66MB.

While I don't know what all the considerations are, from the outside looking in, I think that sooner or later WCG will have to introduce download/upload resume, and I did suggest this in the past for CEP2 [call this the annual bump].

I picked up a total of 26 more CEP2 Betas (about 10days worth), all on reasonably quick systems. I guess the techs want to see some positives with respect to the task allocation before moving to a full all projects beta run. So it could be at least 2 days before that happens.

[slightly OT but still Beta and delivery system related]
I was thinking about the communication deferred period that is invoked subsequent to a rejection of new downloads (say when you chose Betas only and there are none available, or just when communications are down server side). I believe the initial delay is 1h, but can extend to 24h after repeated failures.
Would there be a way to modify this with respect to core count; it might be fine for a slow dual-core CPU to delay further WCG communication for 1h, but for a fast 8 or 12 thread system it can cause issues and we are moving closer to mainstream 16thread systems. Perhaps the delay period could take into consideration the core count or even a combination of core count and performance. So for example, 2 cores=an initial 1h delay, 4cores=30min, 8=15min (for 24/7 systems)... If this could be setup, then it could always be adapted in the future as need be. Just something maybe worth thinking about[/ot-ish]

Good luck,

I've seen much variation. The big files downloaded about 3am (i.e. 12+ hrs ago) took about 15-20 mins. The big files which started downloading after 7am took as much as 70 mins.

BTW, as beta11_qcaux_6.40.zip and beta11.qcaux_v2.zip are identical, I assume the duplicate is there just to put extra strain on the servers (and clients)?