计算操作预计到达时间的最佳方法？

Question

我正在寻找使用线性进度信息计算操作（即：文件下载）的 ETA 的最佳方法。

假设我有以下被调用的方法：

void ReportProgress(double position, double total)
{
    ...
}

我有几个想法：

• 计算设定时间（如最后 10 秒）内的进度，并使用该速度作为操作的平均速度，
• 保留一组最后的结果x 已报告的进度，计算每个增量的速度并使用平均值

Answer 1

事实上，我鄙视这两种想法，因为它们都曾经让我作为开发人员感到困扰。

第一个没有考虑操作实际上变得更快的情况，它说还有10分钟，我3点后回来就完成了。

第二个没有考虑到操作变慢的情况 - 我认为 Windows 资源管理器必须使用此方法，因为它似乎总是花费 90% 的时间复制 90% 的文件，然后用另外 90% 的时间复制最后 10 个文件文件的百分比:-)。

我很早就开始计算这两个数字并对其进行平均。 客户并不关心（他们也并不真正关心其他两个选项，他们只是想看到一些进展），但这让我感觉更好，这就是我真正关心的全部一天结束了;-)

Answer 2

像这样的事情应该可以解决问题：

void ReportProgress(double position, double total)
{
    static TimeType startTime;

    if (position == 0)
    {
        startTime = GetTime();
        return; // to avoid a divide-by-zero error
    }

    TimeType elapsedTime = GetTime() - startTime;
    TimeType estimatedRemaining = elapsedTime * total / position;
    TimeType estimatedEndTime = GetTime() + estimatedRemaining;

    // Print the results here
}

当进度接近 100% 时，估计值会更接近事实

Answer 3

我认为这个问题几乎无法解决，但是通过对正在执行的流程有更多的了解，可以创建一些准确的估计。 在存在大量未知因素的情况下，最好将这些未知因素告知用户，以便他们能够将其考虑在内。

以下载一批文件为例，您有两个已知变量：

• 文件数量
• 文件大小

对于每个文件，都有一个恒定的开销（建立连接所需的时间以及建立连接所需的时间）打开文件系统上的文件）。 下载时间也与文件大小相关。 创建一个可以将其表示为当前下载速度的剩余时间的函数很容易，而且只要下载速度波动不大，就很准确。 但问题就在这里。

有了您正在执行的操作的准确模型，只要没有外部影响，就可以轻松预测需要多长时间。 而这几乎是不可能的。

但是，您可以寻求一种尝试理解和解释这些外部影响的解决方案。 用户可能会发现，当速度发生急剧变化时收到警报很有帮助，因为他们可以调整计划以适应新的预计到达时间。 解释哪些因素正在影响当前的运营也可能会有所帮助。 例如，

Your download will complete in 6 minutes, if the download speed stays at 50k/s

如果用户知道速度可能会改变，则这允许用户做出一些有根据的猜测。 最终减少挫败感。

Answer 4

布拉姆·科恩（Bram Cohen）对此进行了一些讨论。 他在 BitTorrent 中的 ETA 计算上投入了大量精力（但在一次演讲中，他提到还没有人对他说“嘿！BitTorrent 中的 ETA 计算很棒！”）。 这不是一个简单的问题。

一些相关链接：

• http://bramcohen.livejournal.com/24122.html
• http://www.mccaughan.org.uk/g/remarks/time-left .html

Answer 5

如果您想要预计到达时间而不是“进度条”，那么您可以提供多个数字吗？

计算一段时间内的平均下载速度（取决于整个下载可能持续的时间，如果您要查看 10 分钟以上，那么每 5 秒左右就可以了）并记录平均值。

然后您可以提供两个数字，即估算上限和估算下限。

如果您确信平均值能够很好地指示总下载时间，那么您可以显示第 40 个百分位数和第 60 个百分位数 - 如果平均下载时间差异很大，那么第 10 个百分位数和第 90 个百分位数可能会更好。

我宁愿看到一个大概的“21-30 分钟”，并且它是准确的，也不愿被告知 29 分 35.2 秒，而且它相差数英里，并且每次更新之间的差异很大。

Answer 6

这将取决于操作时间的一致性。 如果一致的话，使用之前操作的平均时间就完全合理了。 如果不是，您最好对当前操作进行计时并进行推断。

编辑：如果操作与以前的运行不一致，并且从开始到结束也不一致，那么您将遇到无法解决的问题。 预测不可预测的事情总是很有趣:)

您可能会提前决定是否要低估或高估，并在估计中添加一个模糊因素。 例如，如果您想要高估，并且前 10% 需要 6 秒，您可以外推到 60 秒，然后乘以 1.5 以获得 90 秒的总估计值。 随着完成百分比的增加，减少模糊因子，直到 100% 时变为 1.0。

Answer 7

我从事的项目需要进行长时间、耗时的计算，最终我所做的就是将流程分成相同大小的批次。 然后，我计算计算每个批次所需的时间，并将所花费的时间添加到过去计算时间的 FIFO 列表中。

然后对列表中的时间进行平均，并将所得时间乘以剩余批次的数量。

number of batches = N
size of batch = x
past computations length = l (t0,t1,...,tl)
avg time per batch = (t0 + t1 + ... + tl) / l = t
computed batches = n

ETA = t * (N - n)

注意列表具有固定长度，该长度应该足够长，以便让估计过程“记住”并调整到计算中可能的峰值，但它也应该足够短快速适应计算速度的变化（例如竞争任务结束后的更多计算时间/更多带宽）

Answer 8

我创建了一个用于计算 ETA 的项目。 您可以检查代码，或者如果您有 dotnet 项目，则可以使用 Nuget 包：CalculateETA

在线性迭代上，您可以测量自迭代开始以来经过的总时间，基本上您可以执行以下操作：

(Simple calculation)
ETA = ElapsedTimeForCurrentIteration * (TotalCount - CurrentCount)

(Smoother, less volatile result)
ETA = (TotalElapsedTime / CurrentCount) * (TotalCount - CurrentCount)

如果您使用多线程进程；

(Simple calculation)
ETA = (ElapsedTimeForCurrentIteration) * (TotalCount - CountOfCallingMethod)

(Smoother, less volatile result)
ETA = (TotalElapsedTime / (CountOfCallingMethod) * (TotalCount - CountOfCallingMethod))

您还可以应用其他控制来防止结果或图表出现激增。

GitHub：
https://github.com/meokullu/CalculateETA/

NuGet（DotNet、C#）：
https://www.nuget.org/packages/CalculateETA/

Answer 9

在 Python 中（另存为 timeleft.py）：

"""Time left calculation example, by Cees Timmerman."""

from time import sleep, time

n: int = 10
start = time()
for i in range(n):
    sleep(0.2)
    done = (1 + i) / n
    duration = time() - start
    print(
        f"Done {done * 100:>3.0f} % in {duration:>3,.2f} seconds. "
        f"Time left: {duration / done - duration:>3,.2f} seconds."
    )

输出（使用 python timeleft.py 运行）：

Done  10 % in 0.21 seconds. Time left: 1.87 seconds.
Done  20 % in 0.42 seconds. Time left: 1.69 seconds.
Done  30 % in 0.64 seconds. Time left: 1.48 seconds.
Done  40 % in 0.84 seconds. Time left: 1.26 seconds.
Done  50 % in 1.04 seconds. Time left: 1.04 seconds.
Done  60 % in 1.24 seconds. Time left: 0.83 seconds.
Done  70 % in 1.46 seconds. Time left: 0.62 seconds.
Done  80 % in 1.67 seconds. Time left: 0.42 seconds.
Done  90 % in 1.87 seconds. Time left: 0.21 seconds.
Done 100 % in 2.08 seconds. Time left: 0.00 seconds.