tags:

views:

195

answers:

4

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)?

+8  A: 

Smooth s (exponential moving avg. or similar).

wrang-wrang
Thanks! Looks like a good place to start.
Abhishek
This is actualy just low pass filter.
ralu
A: 

Why not compute the download speed as an average over the whole download, that is:

s = f' / elapsed time

That way it would smooth out over time.

Drew Hall
think of an hour long download at 100kb/s you downloaded 50% of it. Then you started another download and speed goes down 50kb/s your download time indicator will be wrong until the end of your download. It will say 30min remaining while it clearly will take an our to download the rest.
Cem Kalyoncu
Actually, you cannot predict at all how long the second download will take. That second download might be for 50KB total. In that case, you'd show 1 hour remaining for all of 8 seconds, after which it rebounds to 30 minutes. Predicting is hard, especially when it comes to the future :P
MSalters
+3  A: 

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).

Cem Kalyoncu
+8  A: 

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.

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 500.
  • 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
    count = max (maxsz, 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.

paxdiablo