XKCD does it again

[Wudang]

I had a file copy running in the background when I saw this. One of those c|n>k moments



http://imgs.xkcd.com/comics/estimation.png
(http://imgs.xkcd.com/comics/estimation.png)

[Tsukasa Buddha]

Yes, I loved this one as well.

[SkepticScott]

Don't miss the 26 August 2009 strip: http://xkcd.com/628/

[elgarak]

Don't miss the 26 August 2009 strip: http://xkcd.com/628/

One of the best definitions of cold and hot reading (with the mouse-over message)!

[Klimax]

Very funny and in XP very true.

But no longer applies to 7. (So far I can leave it in backjground and speed is unchanged.What changes it of course is performance of devices...)

[Molinaro]

Can anyone beat a progress bar that said: 84,644,256 hours remaining?

I got that when copying aproximately 2600 files totaly about 11 gig off a server onto a workstation. This was about 6 years ago. It was a 10 MBIT network, going from a win2k server to a winxp machine.

It actualy took 3 hours.

*edit to add*

I'm curious if after seeing that number on the progress bar if you would have also waited to see how long it would realy take? It didn't drop under 50 million hours until after 30minutes had gone by. It didn't get under a million until after 1 hour.

[Whiplash]

That is clever, but at the same time, I've always felt that people were slightly unfair in their criticisms of these types of mechanisms in programs. Like the percentage complete bar.

In many cases these are just based on "well we are copying X number of files, so the bar should move one notch for every so many Y files copied", or other similar designs. But of course, files vary in size and other issues.

Are they really supposed to take the time to think "ok, these files will probably take 3 times longer to copy than these.. and these will take 5 times more than those". Are they supposed to experiment with many different machine setups to find "average" times?

I know, it's just humor and not all that serious, and I enjoy it. I'm just being a bit anal, and perhaps defensive from my programming days. Making a perfect, accurate progress bar would be more work than is required for the time in which they are ever even on the screen. Even the windows file copy progress one is more than good enough. It adjusts up and down quite radically at times, when you go from copying a ton of little files to one big one.. sure.. but it's mostly accurate when taken as a whole, and gauged as a whole, isntead of taking it literally every single second.

But still, funny cartoon!

[shadron]

What always gets to me about the bars is that they count up to 99% and then, apparently, the app goes off to do some other kind of housekeeping without taking down the bar and refreshing. So it sits there at 99% for eons.

[CelticRose]

What always gets to me about the bars is that they count up to 99% and then, apparently, the app goes off to do some other kind of housekeeping without taking down the bar and refreshing. So it sits there at 99% for eons.
My mp3 player does that when it's recharging. It zooms up to 99% and then sits there forever before it finally says 100%. That last 1% must be a dilly! :p

[richardm]

Making a perfect, accurate progress bar would be more work than is required for the time in which they are ever even on the screen. Even the windows file copy progress one is more than good enough.

Yeah. I've always thought that the real purpose of progress bars is just to assure you that the program is still alive, rather than giving any accurate indication of how long things are meant to take.

What always gets to me about the bars is that they count up to 99% and then, apparently, the app goes off to do some other kind of housekeeping without taking down the bar and refreshing. So it sits there at 99% for eons.

... which makes this sort of progress bar even more annoying, of course.

[KoihimeNakamura]

Personally I'd rather see that plus in the bottom

"X Files copied at X MiBs (X remaining; y ETA)"

[erlando]

In many cases these are just based on "well we are copying X number of files, so the bar should move one notch for every so many Y files copied", or other similar designs. But of course, files vary in size and other issues.

The problem is that they are keeping track of the wrong number. If I have 4 files where the 3 of them are 1 byte files and the last file is 400 gigabyte the progressbar will be stuck at 75% for a very long time.

This is exactly what Windows (XP) is doing. The absolute worst thing is that the right number is available. It's just not used.

The right way is of course to keep track of the number of bytes copied.

[Wowbagger]

This is exactly what Windows (XP) is doing. The absolute worst thing is that the right number is available. It's just not used.

The right way is of course to keep track of the number of bytes copied. Actually, it looks like Windows IS keeping track of the bytes copied. Simple experiments, you can do yourself, can demonstrate that.

The bar varies in progress because the computer is doing other things in the background, that interrupt the progress. And, sometimes it fills and empties write caches: The bar jumps in progress after a cache is emptied. And stuff like that.

If you are moving files over a network, a lot more things could interrupt the progress.

ETA: Another factor is fragmentation: The more fragments a file is in, the longer it takes to copy. And, also: Lots of smaller files will take longer to copy than fewer large ones, if the total size is equal, because copying the file directory info takes a little time for each one. Especially if it is also updating a search index.

[dasmiller]

That is clever, but at the same time, I've always felt that people were slightly unfair in their criticisms of these types of mechanisms in programs. Like the percentage complete bar.

<snip>

Even the windows file copy progress one is more than good enough. It adjusts up and down quite radically at times, when you go from copying a ton of little files to one big one.. sure.. but it's mostly accurate when taken as a whole, and gauged as a whole, isntead of taking it literally every single second.

In earlier versions of Windows (ISTR that WinME was particularly bad), the problem was much worse than simply uneven countdown. It really would jump around a lot. I remember in the middle of a big file copy watching it smoothly count down from 30 seconds remaining, 20 seconds, 10 seconds, 5 seconds, then 596,513 hours (or some such). . . it would work in that vein for a while, maybe getting to 596,510 hours, then it would jump to 87 hours . . . you really had no idea when it was going to be done.

[Toke]

Personally I'd rather see that plus in the bottom

"X Files copied at X MiBs (X remaining; y ETA)"
My ubuntu partition does something like that.

[shadron]

The problem is that they are keeping track of the wrong number. If I have 4 files where the 3 of them are 1 byte files and the last file is 400 gigabyte the progressbar will be stuck at 75% for a very long time.

This is exactly what Windows (XP) is doing. The absolute worst thing is that the right number is available. It's just not used.

The right way is of course to keep track of the number of bytes copied.

If you are working with an arbitrary tree of files (folders and all their contents, including enclosed folders) then determining how many bytes involved is not a trivial task. You have to recursively walk the tree, opening each file and adding in the number of bytes to the sum total, all before even starting the actual count, and all just to give an indicator about what's going on, rather than doing real work. It is for things like that that some people excoriate Windows and similar systems, wanting to return to simple command line OSs. (Of course, you could do the same thing there, just not as graphically.)

The "right way" is always an opinion and a compromise.

[Wudang]

I'm old-fashioned. Why volunteer the information if it's so unreliable?

[Paul C. Anagnostopoulos]

How about just listing the files as they are copied? Then at least I know something is happening and if I have any notion of how many files I'm copying I can get a feel for how long it's going to take.

Save the bar for when the bar can be reasonably accurate.

~~ Paul

[grmcdorman]

I had an ongoing, um, dialog with a UI specialist about this sort of thing in one of our products. He wanted a progress bar and an estimate of finish time. Unfortunately, the process - segmenting a medical image (such as a CT or MR image) was very non-linear; what's more, the estimate of percent done from the code was very rough and almost never got to 100%.

My argument position was that a remaining time estimate was so unreliable as to be effectively useless.

In the end, we never put in a time estimate, although a progress bar was shown.

[arthwollipot]

It estimates the time remaining based on the time it has taken to do the things it has already done.

[Psi Baba]

It estimates the time remaining based on the time it has taken to do the things it has already done.
That's the pattern I've often noticed. Rather than looking ahead at the rest of the selected files, it seems to assume that the remaining files will be similar to the ones already copied. The bizarre estimates tend to occur earlier in the transfer and seem to become more accurate as it nears completion, unless you throw it a curve like selecting a group of text files and one video file or something.

[arthwollipot]

That's the pattern I've often noticed. Rather than looking ahead at the rest of the selected files, it seems to assume that the remaining files will be similar to the ones already copied. The bizarre estimates tend to occur earlier in the transfer and seem to become more accurate as it nears completion, unless you throw it a curve like selecting a group of text files and one video file or something.Yes - if the files already copied are large, it will estimate a longer time for the remaining files. This makes sense, in a way...

[Little 10 Toes]

Can't remember what I was doing, but I believe I once got a negitive time.

[Wudang]

Can't remember what I was doing, but I believe I once got a negitive time.
That happens to me when I remodulate the deflector grid to emit tachyons or chronometric particles. Plays hell with Outlook.

[grmcdorman]

That's the pattern I've often noticed. Rather than looking ahead at the rest of the selected files, it seems to assume that the remaining files will be similar to the ones already copied. The bizarre estimates tend to occur earlier in the transfer and seem to become more accurate as it nears completion, unless you throw it a curve like selecting a group of text files and one video file or something.

Unfortunately, that's the only way to do it without examining the content of each file - which would make the startup even more expensive. Normally, though, assuming each file is just a stream of binary data should work just fine; there shouldn't be any extra processing going on when copying different file types. It should just be copying the content - the data on the disk - from one location to another.

In other words, I don't see how different file types would have different copying speeds, unless you have something like a virus scanner or DRM getting in the way for some files. Or the file (or disk!) is badly fragmented, which can affect things much more when copying large files.

[TheDaver]

If Windows ever gives you one of those annoying messages telling you it has to restart itself in x minutes, adjust the clock or the calendar for some lulz. ;)