根据吞吐速率推算长时间任务的剩余时间和完成时刻。输入总量、已完成量和处理速度，立即得到剩余耗时与预计完成时间点。
这个任务还要跑多久？ 填入总量、已完成量和当前速率，工具会算出剩余耗时、总耗时，并给出具体的完成时刻。
ETA 本质上就是一次除法：剩余工作量除以速率。还剩 40000 行、每分钟处理 500 行，就是 80 分钟。这个工具帮你完成这次除法，把结果换算成易读的单位，再加到开始时间上，直接给出钟表上的时刻，省去你心算加法的麻烦。
真正麻烦的不是除法，而是这次除法默认「你测到的速率会一直保持到结束」，而这个假设错的次数往往多于对的次数。批量导入会随着索引增大而变慢；下载会在 TCP 慢启动结束后加速；批处理任务可能突然遇到一段异常大的记录。ETA 是对当下的投影，不是对未来的预言——在把这个数字写进进度汇报之前，最好先把这句话说清楚。
因为估算结果完全继承你喂给它的速率，所以「测量窗口」是这个页面上影响最大的输入。取最近十秒的速率，灵敏但抖动剧烈：每看一次都会得到不同的 ETA。取整个运行期的平均速率，稳定但迟钝：任务早就卡住了，它还在报一个乐观的数字。
短任务用全程平均值即可。以小时计的任务，用几分钟的滚动窗口通常最平衡：足够新以察觉变慢，又足够长以忽略偶发抖动。如果两种算法给出的结果差距很大，这个差距本身就是有用的信号——说明速率正在变化，此时诚实的答案是一个区间，而不是一个精确时刻。
工具同时给出总耗时和剩余时间，两者放在一起比单看任何一个都更有信息量。如果任务只完成了 5%，而总耗时显示十一个小时，那么无论剩余时间是多少，你都可以立刻判断：这不是一个应该盯着看的任务。它也提供了一次合理性校验——如果推算出的总耗时和上周同样的任务差得离谱，要么速率测错了，要么确实发生了变化，两种情况都值得在任务跑完之前查清楚。
显示进度百分比也是同样的道理。任务刚开始、完成量还很小时，速率估计建立在极少的样本上，ETA 几乎没有意义。看着百分比往上爬，你才知道这个估算什么时候才积累了足够的数据、值得拿出来引用。