估计/预测下载完成时间

Question

我们都在"剩下的X分钟"对话中嘲笑,这似乎过于简单,但我们怎样才能改进呢？

实际上,输入是直到当前时间的下载速度集合,我们需要使用它来估计完成时间,可能有一定的确定性,例如使用一些Y%置信区间"剩余20分钟".

执行此操作的代码可以放在一个小库中,并在各个项目中使用,所以它真的很难吗？你会怎么做？你对以前的下载速度有什么加权？

或者那里有一些开源代码？

编辑:总结:

1. 通过更好的算法/过滤器等改善估计的完成时间
2. 提供间隔而不是单个时间('1h45-2h30分钟'),或仅限制精度('约2小时').
3. 说明进展何时停滞 - 尽管如果进展一直停滞然后继续,我们应该能够解决这个问题.也许'大约2个小时,目前停滞不前'

Answer 1

更一般地说,我认为您正在寻找一种方法来快速确定传输速度,这通常是通过一小段时间的平均值获得的.

问题通常在于,为了反应,周期通常非常小,这导致yoyo效应.

我会提出一个非常简单的方案,让我们对它进行建模.

考虑曲线速度(y)随时间的变化(x).

1. 即时速度,只不过是读取当前x(x0)的y.

2. 平均速度,不超过 Integral(f(x), x in [x0-T,x0]) / T

3. 我建议的方案是应用过滤器,以便在最后时刻给予更大的重量,同时仍然考虑到过去的时刻.

它可以很容易地实现,因为g(x,x0,T) = 2 * (x - x0) + 2T它是表面T的简单三角形.

现在你可以计算Integral(f(x)*g(x,x0,T), x in [x0-T,x0]) / T,这应该有效,因为这两个函数总是正的.

当然g,只要在给定的时间间隔内它总是正的并且它在间隔上的积分是T(因此它自己的平均值正好为1),你就可以有不同的.

这种方法的优点在于,由于您对即时事件给予更多权重,即使您考虑更大的时间间隔(使平均值更精确,并且更不容易出现打嗝),您仍可以保持相当的反应性.

此外,我很少看到,但认为会提供更精确的估计将关联用于计算平均值的时间与估计的剩余时间:

• 如果我下载一个5ko文件,它将立即加载,无需估计
• 如果我下载15 Mo文件,大约需要2分钟,所以我想估计说每隔5秒钟？
• 如果我下载一个1.5 Go文件,它将需要......大约200分钟(速度相同)...也就是说3h20m ...也许每分钟估计就足够了？

因此,下载的时间越长,我需要的反应越少,我的平均值就越高.一般来说,我会说一个窗口可以覆盖总时间的2%(可能除了少数首次估计之外,因为人们都喜欢立即反馈).此外,一次指示整个%的进展就足够了.如果任务很长,我还是准备等待.

Answer 2

我想知道,状态估算技术会在这里产生好的效果吗？卡尔曼过滤器之类的东西？

基本上,您可以通过查看当前模型来预测未来,并在每个时间步骤更改模型以反映现实世界的变化.我认为这种技术用于估算笔记本电脑电池剩余的时间,也可能根据使用情况,电池使用年限等因素而变化.

有关该算法的更深入描述,请参见http://en.wikipedia.org/wiki/Kalman_filter.

过滤器还提供方差度量,可用于表示您对估计值的置信度(尽管如其他答案中所提到的,向最终用户显示此信息可能不是最佳选择)

有谁知道这是否实际用于某个地方进行下载(或文件复制)估算？

Answer 3

不要提供超出用户需要的信息，从而使用户感到困惑。我正在考虑置信区间。跳过它。

互联网下载时间变化很大。微波炉会干扰 WiFi。使用情况因一天中的不同时间、一周中的某一天、节假日以及新的令人兴奋的游戏的发布而异。服务器现在可能负载很重。如果你把笔记本电脑带到咖啡馆，结果会与在家中有所不同。因此，您可能不能依赖历史数据来预测下载速度的未来。

如果您无法准确估计剩余时间，请不要通过提供此类估计来欺骗您的用户。

如果您知道必须下载多少数据，您可以提供 % Completed Progress。

如果您根本不知道，请提供一个“心跳” - 一段移动的 UI，向用户显示一切正常，即使您不知道还需要多长时间。