Algo for a stable 'download-time-remaining' in a download window

Question

While displaying the download status in a window, I have information like:

1) Total file size (f)

2) Downloaded file size (f')

3) Current download speed (s)

A naive time-remaining calculation would be (f-f')/(s), but this value is way-to-shaky (6m remaining / 2h remaining / 5m remaining! deja vu?! :)

Would there be a calculation which is both stabler and not extremely wrong (showing 1h even when the download is about to complete)?

Answer 1

We solved a similar problem in the following way. We weren't interested in how fast the download was over the entire time, just roughly how long it was expected to take based on recent activity but, as you say, not so recent that the figures would be jumping all over the place.

The reason we weren't interested in the entire time frame was that a download could so 1M/s for half an hour then switch up to 10M/s for the next ten minutes. That first half hour will drag down the average speed quite severely, despite the fact that you're now honkin' along at quite a pace.

We created a circular buffer with each cell holding the amount downloaded in a 1-second period. The circular buffer size was 300, allowing for 5 minutes of historical data, and every cell was initialized to zero.

We also maintained a total (the sum of all entries in the buffer, so also initially zero) and the count (zero, obviously).

Every second, we would figure out how much data had been downloaded since the last second and then:

• subtract the current cell from the total.
• put the current figure into that cell and advance the cell pointer.
• add that current figure to the total.
• increase the count if it wasn't already 300.
• update the figure displayed to the user, based on total / count.

Basically, in pseudo-code:

def init (sz):
    buffer = new int[sz]
    for i = 0 to sz - 1:
        buffer[i] = 0 
    total = 0
    count = 0
    index = 0
    maxsz = sz

def update (kbps):
    total = total - buffer[index] + kbps
    buffer[index] = kbps
    index = (index + 1) % maxsz
    if count < maxsz:
        count = count + 1
    return total / count

You can change your resolution (1 second) and history (300) to suit your situation but we found 5 minutes was more than long enough that it smoothed out the irregularities but still gradually adjusted to more permanent changes in a timely fashion.

Answer 2

Smooth s (exponential moving avg. or similar).

Answer 3

I prefer using average speed for the last 10 seconds and divide remaining part with that. Dividing to current speed to way too unstable while dividing to average of whole progress cannot handle permanent speed changes (like another download is starting).