有哪些好的方法可以预测长流程的完成时间？答案

【问题标题】：What are some good approaches to predicting the completion time of a long process?有哪些好的方法可以预测长流程的完成时间？
【发布时间】：2011-12-02 00:56:25
【问题描述】：

tl;dr：我想预测文件复制完成。考虑到开始时间和当前进度，有什么好的方法？

首先，我知道这根本不是一个简单的问题，预测未来很难做好。对于上下文，我试图预测一个长文件复制的完成。

目前的方法：

目前，我使用的是我自己提出的一个相当幼稚的公式：（ETC 代表预计完成时间）

ETC = currTime + elapsedTime * (totalSize - sizeDone) / sizeDone

这是假设要复制的剩余文件将以迄今为止的平均复制速度进行复制，这可能是也可能不是现实的假设（此处处理磁带存档）。

专业人士：ETC 会逐渐变化，并随着流程接近完成而变得越来越准确。
缺点：它对意外事件反应不佳，例如文件副本卡住或加速过快。

另一个想法：

我的下一个想法是记录最后 n 秒（或几分钟，因为这些档案应该需要几个小时）的进度，然后执行以下操作：

ETC = currTime + currAvg * (totalSize - sizeDone)

这与第一种方法相反：

PRO：如果速度变化很快，ETC 将快速更新以反映当前的事务状态。
缺点：如果速度不一致，ETC 可能会跳跃很多。

终于

我想起了我在大学学习的控制工程科目，其目标本质上是试图让系统对突然的变化做出快速反应，但又不会不稳定和疯狂。

话虽如此，我能想到的另一种选择是计算上述两者的平均值，也许还有某种加权：

如果副本具有相当一致的长期平均速度，则对第一种方法的权重更高，即使它在局部跳跃一点。
如果复制速度不可预测，并且可能会长时间加速/减速或完全停止长时间等操作，则更重视第二种方法。

我真正想要的是：

我给出的两种方法的任何替代方法。
如果以及如何结合几种不同的方法来获得最终预测。

【问题讨论】：

我做过类似的曲线拟合。但它的开销很大，并且只有在现有进度数据中没有太多噪音的情况下才有效。
这里有一些关于所有答案的好建议。很难选择一个“最好的”，但我想我会选择 @aix 的经验方法和有用链接的答案。

标签： algorithm language-agnostic time prediction file-copying

【解决方案1】：

如果您觉得预测的准确性很重要，那么构建预测模型的方法如下：

收集一些真实世界的测量值；
将它们分成三个不相交的集合：training、validation和test；
想出一些预测模型（你已经有两个加上一个混合）并使用 training 集来拟合它们；
检查模型在 validation 集上的预测性能并选择表现最佳的模型；
使用 test 集来评估所选模型的样本外预测误差。

我猜测您当前模型的linear combination 和“过去 n 秒的平均值”对于手头的问题会表现得很好。可以使用linear regression（R 中的单线）拟合线性组合的最佳权重。

Hastie、Tibshirani 和 Friedman 的 The Elements of Statistical Learning 是学习统计学习方法的绝佳资源。我对这本书的推荐程度再怎么不过。

最后，您的第二个想法（过去 n 秒的平均值）尝试测量瞬时速度。一个更强大的技术可能是使用Kalman filter，其目的正是：

其目的是使用随时间观察到的测量值，包含噪声（随机变化）和其他不准确，并产生值往往更接近测量的真实值和它们关联的计算值。

使用卡尔曼滤波器而不是固定的 n 秒滑动窗口的主要优点是它是自适应的：当测量值跳动很多时，它会自动使用更长的平均窗口，而不是它们时重新稳定。

【讨论】：

我喜欢这里的经验方法。这些链接看起来也很有用。

【解决方案2】：

我已经实施了两种不同的解决方案来解决这个问题：

当前传输在开始时的 ETC 基于历史速度值。每次传输后都会对这个值进行细化。在传输过程中，我会计算历史数据和当前传输数据之间的加权平均值，这样越接近结束，传输的实际数据的权重就越大。
不显示单个 ETC，而是显示时间范围。这个想法是从最后'n'秒或分钟计算ETC（就像你的第二个想法）。我跟踪最好和最坏情况的平均值，并计算一系列可能的 ETC。这在 GUI 中显示有点令人困惑，但可以在命令行应用程序中显示。

【讨论】：

不错的建议。这些方法有点不同，不是我能想到的。

【解决方案3】：

恕我直言，ETC 的糟糕实现被过度使用，这让我们可以have a good laugh。有时，显示事实而不是估计可能会更好，例如：

已复制 10 个文件中的 5 个
已复制 200 MB 中的 10 个

或显示事实和一个估计，并明确它只是一个估计。但我不会只显示一个估计值。

每个用户都知道 ETC 通常是完全没有意义的，然后很难区分有意义的 ETC 和无意义的 ETC，尤其是对于没有经验的用户。

【讨论】：

是的，无论我使用哪种方法，我肯定还是会以原始数字显示进度。

【解决方案4】：

这里有两点需要考虑：

准确的估计
如何呈现给用户

1.关于估计

除了统计方法之外，在消除一些噪声或尖峰的同时对当前速度进行良好估计的一种简单方法是采用加权方法。

您已经对滑动窗口进行了实验，这里的想法是采用一个相当大的滑动窗口，但不是一个简单的平均值，而是给最近的度量更多的权重，因为它们更能指示进化（有点像衍生物）。

示例：假设您有 10 个之前的窗口（最近的 x0，最近的 x9），那么您可以计算速度：

Speed = (10 * x0 + 9 * x1 + 8 * x2 + ... + x9) / (10 * window-time) / 55

如果您对可能的速度有一个很好的评估，那么您就可以得到一个很好的估计时间。

2。演示中

这里要记住的主要一点是，您需要良好的用户体验，而不是科学前沿。

研究表明，用户对减速的反应非常糟糕，而对加速的反应非常积极。因此，一个好的进度条/估计时间首先应该在所呈现的估计中保守（为潜在的减速保留时间）。

一个简单的方法是有一个完成百分比的因素，您可以使用它来调整估计的剩余时间。例如：

real-completion = 0.4
presented-completion = real-completion * factor(real-completion)

其中factor 等于factor([0..1]) = [0..1]、factor(x) <= x 和factor(1) = 1。例如，三次函数对完成时间产生了很好的加速。其他函数可以使用指数形式1 - e^x等...

【讨论】：

这里有更多我没想到的有趣想法。