当然,你可以将剩余的文件大小除以当前的下载速度,但是如果你的下载速度波动(它将会),这不会产生一个非常好的结果。有没有更好的算法来产生更平滑的倒计时?
发布于 2017-06-16 06:08:24
几年前,我写了一个算法来预测磁盘映像和多播程序中的剩余时间,当当前吞吐量超出预定义范围时,该程序使用移动平均值并进行重置。它将保持平稳,除非发生极端情况,然后它将快速调整,然后再次返回移动平均线。请参阅此处的示例图表:
该示例图表中的蓝色粗线是一段时间内的实际吞吐量。请注意,在传输的前半部分,吞吐量很低,然后在后半部分急剧上升。橙色的线条是整体平均值。请注意,它从来没有调整到足够远的程度,无法准确预测完成需要多长时间。灰色线条是移动平均值(即最后N个数据点的平均值-在此图中,N是5,但实际上,N可能需要更大才能足够平滑)。它恢复得更快,但仍然需要一段时间来调整。N越大,需要的时间越长。因此,如果您的数据非常嘈杂,那么N将不得不更大,恢复时间也将更长。
绿线是我使用的算法。它就像移动平均线一样,但当数据移动到预定义的范围之外(由浅而细的蓝色和黄色线条表示)时,它将重置移动平均线并立即向上跳跃。预定义的范围也可以基于标准差,因此它可以根据数据的噪声程度自动调整。我只是把这些值放到Excel中,为这个答案绘制图表,所以它并不完美,但你明白了。
然而,可以人为地设计数据,使该算法不能很好地预测剩余时间。底线是,您需要对数据的行为有一个大致的了解,并选择相应的算法。我的算法对我看到的数据集工作得很好,所以我们一直在使用它。
另一个重要的提示是,开发人员通常会在进度条和时间估计计算中忽略安装和拆除时间。这会导致永久的99%或100%进度条在那里停留很长时间(当缓存被刷新或其他清理工作正在发生时),或者当扫描目录或其他设置工作发生时狂野的早期估计,累积时间但不累积任何百分比的进度,这会抛出所有事情。您可以运行多个测试,其中包括设置和拆除时间,并根据作业大小或平均时间估计这些时间,然后将该时间添加到进度条中。例如,前5%的工作是设置工作,最后10%是拆卸工作,然后中间的85%是下载或您跟踪的任何重复过程。这也会有很大帮助。
发布于 2010-10-02 01:40:09
对于这一点,exponential moving average非常有用。它提供了一种平滑平均值的方法,以便每次添加新样本时,较旧的样本对总体平均值的重要性逐渐降低。它们仍然被考虑,但它们的重要性呈指数级下降--因此得名。由于它是一个“移动”平均值,你只需要保持一个数字。
在测量下载速度的上下文中,公式将如下所示:
averageSpeed = SMOOTHING_FACTOR * lastSpeed + (1-SMOOTHING_FACTOR) * averageSpeed;
SMOOTHING_FACTOR
是一个介于0和1之间的数字。该数字越大,丢弃旧样本的速度就越快。正如您在公式中看到的,当SMOOTHING_FACTOR
为1时,您只需使用上一次观测的值。当SMOOTHING_FACTOR
为0时,averageSpeed
从不更改。因此,你想要一些介于两者之间的东西,通常是一个较低的值来获得良好的平滑效果。我发现对于平均下载速度,0.005提供了一个相当好的平滑值。
lastSpeed
是最后测量的下载速度。您可以通过每秒钟运行一次计时器来计算自上次运行以来已下载的字节数,从而获得此值。
显然,averageSpeed
是您想要用来计算估计剩余时间的数字。将其初始化为您获得的第一个lastSpeed
度量。
发布于 2010-05-06 16:38:03
speed=speedNow*0.5+speedLastHalfMinute*0.3+speedLastMinute*0.2
https://stackoverflow.com/questions/2779600
复制相似问题