Estimates

Hard Problems are Hard

You need only look at Apple’s installer, sitting at “one minute left” for an hour, to understand that time estimates of I/O-based operations are very hard.

They seem like they’d be easy, though, don’t they?¹ You just take the size, figure out how fast things are going, and do some math, and bingo-bango-bongo, there you go! Perfect estimate!

Similarly, you take something like the Blackmagic Disk Speed Test and look at its read/write speed and think “geez, there’s the speed, what’s the problem”?

I mean, sure: if you were writing a single file (or some big files), to a blank destination, on a consistent connection. Bytes stream at a constant rate, and it really is just a matter of a few quick observations and a little math.

Real World Cases

But, no. It’s not that simple. I tried the best I could to get things as right as possible, and the estimates are still, sometimes, wrong.

Sometimes very wrong.

Let me walk you through the general (albeit highly simplified) approach:

• SuperDuper walks the drive and calculates about how much data has to be copied (while, at the same time, it’s copying)
• Once it knows, it looks as the rate copying is going
• It then shows you a time

Sounds familiar, right? Well, it goes further than that:

• It’s actually showing a moving average that’s taking speed variances into account
• It’s determining the approximate ratio of “up to date” vs “need to copy” files
• It’s figuring out how long it’s taking to copy small vs big files
• It’s taking previous runs against this content into account
• …and so much more…

Even with all that, sometimes it’ll be wrong.

I just don’t know, until I get there, whether something is going to need to be copied. If it doesn’t, and it’s large, the estimate will be too long. If it does, and the OS is slow to copy that particular file, or that size of file, it’ll be too short.

You get the idea. Hopefully.

“Your Estimates Suck, and So Do You”

For years, I resisted putting in anything like this. It’s just too hard to give an accurate number. But as I shaped the algorithms I’m using in SD4, I figured I could get close, most of the time, in most situations, and it would be worthwhile.

And I think it is. Usually. Sometimes it’s wrong…but it gets better the more you copy that particular content.

It’ll never be perfect, though (although I get very close for replication, which was very tricky, given Apple’s replicator gives virtually no information about what it’s doing, and certainly no speed or even size info), and I try to indicate that with lots of hedging and “weasel words” like approximately and about and estimate to tell you that, well, an estimate is an estimate. It’s an inexact science.

So, if the estimate I’m presenting annoys you, you may want to consider taking the Car Talk “engine check light” approach: put a piece of black electrical tape over it.

Or just close the window. The copy will continue in the background and finish when it finishes.

Problem solved!