在许多应用程序中,我们为文件下载,压缩任务,搜索等提供了一些进度条.我们经常使用进度条让用户知道正在发生的事情.如果我们知道一些细节,例如已完成了多少工作以及剩下多少工作,我们甚至可以通过推断从达到当前进度水平所需的时间来估算时间.
压缩ETA截图http://jameslao.com/wp-content/uploads/2008/01/winrar-progress-bar.png
但我们也看到这个时间留下"ETA"显示的程序只是滑稽的坏.它声称文件副本将在20秒内完成,然后一秒后它会说需要4天,然后再次闪烁20分钟.它不仅无益,而且令人困惑!ETA变化如此之大的原因是进度本身可能会有所不同,程序员的数学运算可能过于敏感.
苹果公司通过避免任何准确的预测并仅仅给出模糊估计来回避这一点! Apple的模糊逃避http://download.autodesk.com/esd/mudbox/help2009/images/MED/DaliSP1/English/Install_licensing/install_progress_MAC.png
这也很烦人,我有时间快速休息,还是我的任务将在2秒内完成？如果预测太模糊,那么完全做出任何预测毫无意义.
简单但错误的方法
作为第一次通过ETA计算,可能我们都只是做一个函数,如果p是已经完成的小数百分比,t是到目前为止所用的时间,我们输出t*(1-p)/ p作为估计完成需要多长时间.这个简单的比例可以"正常",但它也很糟糕,特别是在计算结束时.如果你的缓慢下载速度让副本慢慢地在一夜之间发生,最后在早上,一些东西开始运行,副本开始全速前进,速度提高了100倍,你完成90%的ETA可能会说"1小时",10秒之后你会达到95%而且ETA会说"30分钟",这显然是一个令人难以置信的糟糕猜测.在这种情况下,"10秒"是一个非常好的估计.
当发生这种情况时,您可能会考虑更改计算以使用最近的速度而不是平均速度来估算ETA.您可以获取过去10秒内的平均下载速率或完成率,并使用该速率来预测完成时间.这在之前的一夜之间下载过程中表现相当不错,因为它将在最后给出非常好的最终完成估算.但是这仍然存在很大问题..当你的速率在很短的时间内快速变化时,它会导致你的ETA大幅反弹,你会得到"在20秒内完成,在2小时内完成,在2秒内完成,在30秒内完成"分钟"快速显示编程耻辱.
实际问题:
在给定计算的时间历史的情况下,计算任务完成的估计时间的最佳方法是什么？我不是在寻找GUI工具包或Qt库的链接.我问的算法是生成最理智和准确的完成时间估计.
你有数学公式的成功吗？某种平均值,可能是使用超过10秒的速率平均值,速率超过1分钟,速率超过1小时？某种人工过滤,例如"如果我的新估计值与之前的估计值相差太大,请将其调低,不要让它反弹太多"？某种奇特的历史分析,您可以将进度与时间进度相结合,找到速率的标准偏差,以便在完成时给出统计误差指标？
你尝试了什么,什么效果最好？
可能重复:
估计/预测下载完成时间
我们都看到下载时间运行估计最初表示"7天"之类的事情,但是随着每次连续估计而不断下降(例如"23小时","45分钟","1分50秒"等)随着块的下载.
为了避免这些初始(警报)估计,有些技术可以尝试抑制前n个估计的显示,或等待估计之间的差值在开始显示之前降至某个阈值以下,但这些似乎不是一般,稳健的解决方案 有一些涉及太少样本的角落案例,或实际上变化很大的样本......
我想我回忆起数学(统计学)这类事物的一般解决方案,它可以减少或消除这些疯狂的价值观.
有人知道吗？
好的,看起来这已经被问到并回答了:
估计/预测下载完成时间
我的问题甚至以与此相同的措辞开始.滑稽...
