algorithm - 下载窗口中稳定 'download-time-remaining' 的算法

Question

在窗口中显示下载状态时，我有如下信息:

1) 文件总大小 (f)

2) 下载文件大小(f')

3) 当前下载速度(s)

天真的剩余时间计算是 (f-f')/(s)，但这个值是不稳定的(剩余 6 米/剩余 2 小时/剩余 5 米!似曾相识？!:)

有没有比较稳定的计算，又不是特别错误(即使下载快要完成，也显示1h)？

Answer 1

我们通过以下方式解决了类似的问题。我们对下载在整个时间内的速度有多快不感兴趣，只是根据最近的事件预计大约需要多长时间，但正如您所说，不是最近的数据到处乱跳。

我们对整个时间范围不感兴趣的原因是下载可能会以 1M/s 的速度持续半小时，然后在接下来的十分钟内切换到 10M/s。前半小时会严重拉低平均速度，尽管您现在以相当快的速度按喇叭。

我们创建了一个循环缓冲区，每个单元格保存 1 秒内的下载量。循环缓冲区大小为 300，允许 5 分钟的历史数据，每个单元格都初始化为零。

我们还维护了总数(缓冲区中所有条目的总和，因此最初也为零)和计数(显然为零)。

每一秒，我们都会计算出自上一秒以来下载了多少数据，然后:

• 从总数中减去当前单元格。
• 将当前图形放入该单元格并推进单元格指针。
• 将当前数字添加到总数中。
• 如果尚未达到 300，请增加计数。
• 根据总数/计数更新显示给用户的数字。

基本上，在伪代码中:

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

您可以更改您的分辨率(1 秒)和历史记录 (300) 以适合您的情况，但我们发现 5 分钟的时间足以消除不规则现象，但仍会及时逐渐适应更永久的变化。