Vista boasting about throughput

This is yet another of those "Explorer Copy Estimated Time" bugs, but not THE "Explorer Copy Estimated Time" bug that gets fixed by the KB938979 hotfix MS released (described here).

I've always found the concept of estimating the remaining time for a massive file copy/move operation rather intriguing, given the combinations of where the source and destination hard disks are physically located. Data transfer may temporarily slow down, or it may gradually slow down, or it may oscillate between slow and fast every minute or so (depending on who knows what). I think that deciding which is the most meaningful time window for doing the throughput calculation displayed to the user and deciding the remaining time can be very tricky.

Since it is a tricky issue I would have thought that the Vista team paid some more attention to the issue. Noone forgets the embarassing "17482634 minutes remaining", then "24 minutes remaining", then "10943 minutes remaining", etc, of Windows XP.

Anyway, earlier this evening I started a file copy over an Ethernet 100Mbps network between an old PIII 733 running Windows 2000 and my brand new Vista PC. At some point in the process I noticed the contents of the copy progress dialog:

Wow64, I thought! 5.76GB in "about 5 seconds"??? That's awesome! That's throughput greater than 1GByte/sec. Now that's what I call a confident OS :-)
At the very same time the current speed was being reported as 628KB/sec.

I decided there and then that this was "Funny Software" material, so I started to follow how will Vista recalculate the remaining time as the copy operation progresses.

A couple of minutes later, this was our status:

0.7GB of data later and Vista hadn't changed it's mind yet. The throughput seemed to improve, but I really could not take any of the throughput numbers seriously. 0.7GB at any speed that is indicated in KB/sec would have taken at least 10-15 minutes, but I definitely not waited that much before I got the second screenshot.

Then after a little while a file copy completed and there were less items remaining. It seems that the Vista team thought that was a proper place to update their statistics:

Now they are getting a bit more realistic I have to admit: 4.83GB in 30 seconds going at 1,04MB/sec. I don't know, maybe they used the buggy Excel engine to do their math.

Following futher on, it seems that they are not updating the statistics only on file conclusion:

Midway through the 9th file, after a mere 0.13GB, Vista decided that it should pump up its estimate to 1 min and 15 sec, given the fact that the throughput improved as well. That's some strange math...

When the 9th file concluded, there was yet another slightly more modest estimate:

I don't know about you, but I am really curious about the logic behind this. I mean, more than 1.5GB had been copied between the first and the last screenshots, but still Vista thinks it has super natural powers.
It kind of reminds me of some code a coworker once wrote, that was only compiled but never tested; it first run on the customer site. It didn't crash, but our consultants got really strange results, almost random, results that they could not "figure out" no matter how hard they tried. Of course they had no idea what an "ininitialized variable" was or what a mess it is capable of causing.
Here it seems that the (4127-10) items that were copied at the beginning of this copy operation have affected calculations so badly that the situation cannot be salvaged.

Have Fun!
Dimitris Staikos

Comments

[x]

this issue is really annoying. you were asking about the logic behind it. vista calculates the remeining time based on the NUMBER OF ITEMS PER SECOND and not on throughput. who made this fucking descision at microsoft?

[adamo]

Hmm... Inside Vista SP1 File Copy Improvements:

http://blogs.technet.com/markrussinovich/archive/2008/02/04/2826167.aspx

[adamo]

Can you verify if the situation is the same after issuing (as an administrator) from the command line a "netsh interface tcp set global autotuninglevel=restricted" ?

I am trying to verify which scenarios are excluded by =restricted that =normal does not exclude and have not found any specific documentation by M$.