计算文件副本/移动的估计时间？

Question

本xckd cartoon我不知道什么是提供一个估计将文件复制/移动的用户的最佳机制的启发？

上XKCD的ALT标签内容如下：

他们可能会说“的连接可能丢失，”但它更有趣的事情天真的时间平均给你希望，如果你在附近等1,163小时，它会最终完成。

忽略这个有趣的事实，它是如何在Windows中完成的？其他操作系统如何？有没有更好的办法？

Answer 1

看看my answer to a similar question（以及那里的其他答案），了解如何在Windows资源管理器中估计剩余时间。

在我看来，只有得到良好的估算方法之一：

• 计算开始在复制过程之前要复制的字节的确切数字
• 重新计算您定期估计（每1， 5或10秒，YMMV）基于当前传输速度
• 当您在网络上进行复制时，当前传输速度可能会大幅波动，因此请使用平均值，例如根据自上次估计以来传输的字节数。

请注意，如果您要复制许多文件，第一点可能需要很多工作。这可能就是为什么来自微软的人决定放弃它的原因。您需要确定自己是否值得为用户提供更好的估算，从而计算出的额外开销。

Answer 2

最重要的是我永远不会显示秒（只有几小时和几分钟）。我认为当你坐在那里等待一分钟，而计时器跳过10到20秒时，真的很令人沮丧。并始终显示真实的信息，如：xxx/yyyy MB复制。

我也包括这样的事情：

if timeLeft > 5h --> Inform user that this might not work properly 
if timeLeft > 10h --> Inform user that there might be better ways to move the file 
if timeLeft > 24h --> Abort and check for problems 

我也会在所估计的时间而变化太多

如果这不是太复杂，应该有通知用户一个自动检查功能，用于检查进程是否仍然存在，并且每1-10分钟工作一次（取决于应用程序）。

Answer 3

谈到网络文件副本，最好的办法是计算要传输文件的大小，网络响应等，我曾经曾经是一个办法：

连接速度=中国平安和计算往返时间与15千字节的包。

让我的文件大小，看看，theorically，如果我会用我的连接速度打破它在 15 kb的包需要多少时间服用。

转移开始后重新计算我的连接速度，并调整将要耗费的时间。

Answer 4

我已经做了一些类似的估计，当一个队列将是空的时候，考虑到这些项目的入队速度比入队更快。我使用最近的N次读数（时间，队列大小）进行线性回归。

这给了更好的结果不是一个天真的

(bytes_copied_so_far/elapsed_time) * bytes_left_to_copy 

Answer 5

• 启动一个全球性的计时器，大火说，每1000毫秒和更新总elpased时间计数器。我们称这个变量为“elapsedTime”
• 在复制文件时，用已经复制的数量更新某个局部变量。我们称这个变量为“totalCopied”
• 在定期发生的定时器事件中，将totalCopied除以totalElapsed以给出每个定时器间隔（本例中为1000ms）复制的字节数。我们称这个变量为“bytesPerSec”
• 将总文件大小除以bytesPerSec并获得理论上复制此文件所需的秒数。我们称这个变量为remainingTime
• 从remainingTime减去elapsedTime并且您对文件复制时间有些准确的计算。

Answer 6

我认为对话应该承认它们的局限性。这并不烦人，因为它没有给出有用的时间估计，这是令人讨厌的，因为它权威地提供了一个明显无稽之谈的估计。

因此，根据目前的利率或平均利率来估算你喜欢的，滚动平均数，丢弃异常值等。取决于将其延迟的事件的操作和典型持续时间，因此，如果知道文件副本涉及网络驱动器，则可能有不同的算法。但是，除非你的估计在一段时间内相当一致，等于30秒或者估计时间的10％，那么显示“哦，亲爱的，当它大幅放慢时，似乎有某种滞留”，或者忽略如果它大幅度加速的话。

例如，在1秒间隔拍摄对话框中的消息时，连接简单档：

remaining: 60 seconds    // estimate is 60 seconds 
remaining: 59 seconds    // estimate is 59 seconds 
remaining: delayed [was 59 seconds] // estimate is 12 hours 
remaining: delayed [was 59 seconds] // estimate is infinity 
remaining: delayed [was 59 seconds] // got data: estimate is 59 seconds 
// six seconds later 
remaining: 53 seconds    // estimate is 53 seconds 

Answer 7

我一直在琢磨这一个自己。我有一个复制例程 - 通过Windows资源管理器风格的界面 - 它允许从Android设备传输选定的文件到PC。

在开始时，我知道要复制的文件的总大小，并且在使用C＃.NET时，我使用秒表来获取已用时间，并且在复制正在进行中，我以字节为单位保留了迄今为止复制的内容。

我没有实际测试过，但最好的办法似乎是这样的 -

经过估算= *（（总计TOTALSIZE - copiedSoFar）/ copiedSoFar）