xkcd

我知道Windows复制对话框（在Windows XP中）首先将副本存储在内存中，并且在对话框关闭后仍在复制，因此时间已到，但是为什么要估算复制时间呢？即使在禁用内存复制的情况下（在Vista和Windows 7中），它还是不准确吗？似乎太武断了！整个复制过程如何工作，为什么Windows无法正确估计它？

简而言之：较差的算法和快速估计实际上是实现上的弱点。

像TeraCopy这样的其他工具做得更好。我认为没有必要解释为什么它们的实现不好。他们会注意到这一点，并且会有所改善。

难点：

1. 您必须考虑资源波动（主要是CPU /网络带宽/ HDD速度）
2. 您需要通过预测行为来推断所需的时间（Windows文件复制现在肯定会造成的不良影响）。
3. 随时间调整您的原始估算（我的意思是小调整，不同于上面的有趣图片！）

为此，不仅字节数量而且要创建的文件数量都起作用。如果您有一百万个1KB文件或数千个1MB文件，情况将大不相同，因为前者具有创建许多文件的开销。根据所使用的文件系统，这可能比实际传输数据花费更多的时间。

这个对话框让我发疯了很多次：

• 在较旧的WinNT系统上，如果要复制很多小文件，它将显示每个文件的名称和漂亮的动画，从而使整个过程变慢，几乎无法使用。

现代Windows复制的东西并没有好得多：

• 要计算要传输的数据量，它似乎首先要进行查找（这是我想做的），因此，如果您选择许多目录，直到它开始有效地工作，它会花费一些时间。
• 一些内置的超时弹imp要复制的大文件（我的系统上大于60GB）。痛苦的是，它告诉您在网络上已经复制了超过30GB的内容后，这将浪费带宽和时间，因为您必须从头重新启动！
• 由于某种原因，文件从一台计算机到另一台计算机的复制速度太慢了。（我的意思是，与可用的网络带宽相比，使用其他工具更快，因此这不是计算上的限制。）

Raymond Chen曾经写过一篇很好的文章。基本上，对话框只是猜测：)。

http://blogs.msdn.com/b/oldnewthing/archive/2004/01/06/47937.aspx

“因为复制对话框只是猜测。它无法预测未来，但是它不得不尝试。在复制的开始，当经历的历史很少时，预测可能会很糟糕。

这是一个比喻：假设有人告诉您，“我要数到100，并且您需要对我何时完成进行连续估算。” 他们开始说：“一，二，三...”。您会注意到它们以每秒大约一个数字的速度运行，因此您估计需要100秒。呃，现在他们在减速。“四个…………五个…………”现在，您必须将估算值更改为200秒。现在它们加快了速度：“六七八十九”您必须再次更新估算。

现在，仅听取您的估计而不听取计数的人以为您不满意。您的估计从100秒减少到200秒减少到50秒。你怎么了？你为什么不能给个好估计？

文件复制是一回事。Shell知道要复制多少文件和多少字节，但不知道硬盘，网络或Internet有多快，因此只需要猜测即可。如果副本的吞吐量发生变化，则需要更改估计值以考虑新的传输速率。”

我要数到十，要达到十个1....2....3....4点需要多少个点？

5.6.7现在呢？您是否考虑了数字之间的所有过去点并取其平均值，是否只取了最后4个间隔并使用该平均值，是否只看了最后一个间隔？

您在文件传输方面遇到了同样的问题。文件传输的速度不是恒定的，它会根据许多因素加快和降低速度。这个数字跳得如此之多的原因是微软倾向于频谱的“仅计算最后一个间隔”。

频谱的那边没有问题，它为您提供了更准确的“每秒”（每秒1秒钟使计数器下降了1秒钟），但是这导致计时器的总ETA跳了很多。

压缩时，相反的一个很好的例子是7-Zip。如果压缩速度在处理过程中下降，您会发现ETA不会像文件传输ETA那样急剧跳动，但可能需要2到3真实秒才能使计时器下降一秒钟（甚至可能开始计数） ），直到以新的速度稳定下来。

微软的Raymond Chen对于WAAAAAY的回答实际上是一个近乎规范的答案，还有一些难题。

因为复制对话框只是猜测。它无法预测未来，但不得不尝试。并且在复制的开始，如果没有什么历史记录，那么预测可能会很糟糕。

首先，Windows正在猜测。它知道有多少个文件，有多少个文件，但是每个文件的传输速率变化很大。在某些情况下，它取决于大小，甚至驱动器上的位置。随着时间的流逝，它会根据当前和过去的条件来调整其猜测，因此您在实际条件下的估计传输速度不准确。

这里的解释由雷蒙德陈，微软首席软件设计工程师：

为什么复制对话框给出了如此可怕的估计？

因为复制对话框只是猜测。它无法预测未来，但不得不尝试。并且在复制的开始，如果没有什么历史记录，那么预测可能会很糟糕。

这是一个比喻：假设有人告诉您，“我要数到100，并且您需要对我何时完成进行连续估算。” 他们开始说：“一，二，三...”。您会注意到它们以每秒大约一个数字的速度运行，因此您估计需要100秒。呃，现在他们在减速。“四个…………五个…………”现在，您必须将估算值更改为200秒。现在它们加快了速度：“六七八十九”您必须再次更新估算。

上面引用的博客文章对此问题进行了长时间的讨论，并给出了一些有趣的评论。

雷蒙德·陈（Raymond Chen）是一位传奇人物，“微软的查克·诺里斯（Chuck Norris）”，我认为您不会得到更权威的答案。我确定他至少看过有问题的代码。

显而易见的原因是传输速度随时间变化，平均值也变化，预测也变化。为了向非技术朋友解释这一点，我使用了一个比喻，其中涉及乘飞机旅行。您将飞越大西洋。当您乘坐出租车到达出发机场时，您的预计到达时间约为两个月。当您以目前的平均速度在到达机场下船时，您将在5秒钟内到达朋友家。

但是，即使在看起来像是可预测的情况下，例如在同一磁盘中或在两个本地磁盘之间复制文件，您也需要了解速度的实际变化幅度。我喜欢Windows 8中的新功能之一，就是如果您单击“更多详细信息”，就可以绘制速度随时间变化的图表。如果您无权使用Windows 8计算机，请在Windows 8复制对话框中搜索图像以获取很多示例。它们中的许多都比较平整，但是它们中的许多也令人不安地颠簸，以至于使您怀疑硬盘驱动器跌至零时它是否实际上是健康的。

其中一些障碍可能是由于文件大小的变化而引起的-较小的字段产生更多的访问，这会减慢速度，特别是在必须通过移动读取磁头来寻找的机械硬盘上-但有些则可能只是便宜的驱动器稍稍停顿即可防止损坏盘子。

ETA预测算法有好有坏，但是对于准确的预测，计算机必须是一窍不通的。尝试使算法“更智能”的风险在于，它可能会产生新的，无法预料的情况，甚至更可笑。

知道压缩一组文件需要多长时间的唯一方法是压缩它们。有时Windows最好的猜测是接近的，有时这是完全错误的。我相信您已经注意到，复制大量文件也是如此。

与其说是错误的显示，还不如说是很少显示不准确的信息。解决它的最好方法是闭上眼睛。忽略它。;-)

也许那里有一个程序可以复制/压缩文件并在完成时发出警报声。那将是真正有用的。在等待Windows完成房屋清洁时，我们可能需要小睡一下。

我认为原因在Roald的答案所链接的博客文章的评论之一中得到了很好的解释：

它有一个可怕的估计算法。没有任何借口。如果必须复制1000个1KB文件和10个1MB文件，它认为1MB文件和1KB文件一样忙。

它给出如此可怕的估计的原因是它做得不好。显然，它永远不可能是100％精确的，但是可能会好得多。

为了加快复制过程（而不是花费太多时间来计算时间估计而不是执行与复制相关的操作），资源管理器中内置的Windows复制实用程序维护了有关先前写入操作完成速度的有限信息。每次需要计算剩余时间时，它只计算出写操作所花费的平均时间，然后乘以剩余写操作数。

问题是执行写操作所花费的时间不是恒定的-实际上它可能会发生很大的变化。因此，这反过来会导致时间估计发生重大变化。

有3个因素需要考虑：

1. 传输的总大小。
2. 要传输的文件数。
3. 媒体的“繁忙度”，可能还有连接。

数字1和3似乎对转移时间的计算影响最明显，但是很多人没有考虑数字2。这可能会对转移进行多长时间产生巨大影响，并且难以量化。

基本上，每次写入文件时，文件系统都需要写入一些有关该文件的元数据，例如。所有权，许可权，创建/修改/访问时间等。根据特定的文件系统，此信息可能会被写入磁盘中与文件写入位置“相距甚远”的部分。这种文件系统开销可能会使看似简单的传输花费很长时间，并且/或者使时间估算值波动很大。

例如：传输一个大文件，您会注意到估算值保持稳定并且相当准确，但是传输数百个大小不同但总大小相同的文件可能会花费更长的时间，并且会导致时间估算与实际情况不符。

当前的估计算法存在三个缺陷。

与普遍的看法相反，它们几乎没有困难到足以举起我们的双手。

由于学习领域和学历的广度，大多数人写博客以及这里的人都不知道这种可能性的原因是我所能说的最好的。对于[受过培训且比博客撰写者要晚的毕业生] [一家市值数十亿美元的公司]微软，应该有可能采取一种温和而又非常舒适的补救措施。

我将尝试粗略地解释原因。

故障点如下。内核：

1. 由于内核范围之外的情况，无法可靠地预测将来的IO负载

• 这是一个无穷无尽的P = NP问题，因此无需采取任何措施。

2. 没有以任何有用的详细程度跟踪IO启发式方法。利用率是比磁盘/网络读/写速度更广泛的概念。

• 对此几乎不需要做任何事情，仅需跟踪最基本的IO使用信息即可。

  • 从磁盘
    • 平均读取速度尺寸1a
    • 文件的平均写入速度2a
  • 根据每个数量*
    • 文件的大小尺寸b
    • 文件在磁盘尺寸c上的位置
  • *量化为[可能]不超过3个类别。降维将有助于我们确定某些因素，但对于（好于有效）优于一切的预测机制，3应该足够：
    • 文件大小
      • 光
      • 介质
      • 重
    • 位置[搜寻等待时间通知]
      • 开始
      • 中间
      • 你明白了
    • 文件大小和位置是多余的/与读/写速度重叠，这是有意的
  • 我们需要知道磁盘的“繁忙程度”，以便我们可以假设它将继续成为繁忙维度d
    • 根据读取的文件数量计算得出，并加上各自的权重
    • 用于估计复制开始时的时间...基于将来的预期负载的对话框，如果此复制对话框之外的所有其他内容仍按原样继续
  • 以...为目的的记录方法在此已申请专利

3.如果他们被跟踪，将不会用于启发式

• 在这里，我们所做的大部分工作都做得很少
• 这是我们将第二个数据用于
  • 文件权重和位置的粗略统计分析，以确定我们要进行多少次跳跃。权重+位置给我们一个预测
  • 结合当前磁盘负载权重和位置
  • 估计我们所认为的文件数量的平均读取/写入速度尺寸f会
  • 我们进行比较以微调我们的模型
  • 这将使我们相当准确地估计进度条和完成时间
• 为预测目的而进行分析的方法...此处已申请专利

这一切的关键是我们的模型只有2a = F *（bxc）+ d复数

其中a，b和c分别具有3种状态：文件管理器在复制之前先查看文件（或只是元数据），而F *（bxc）+ d并不是昂贵的计算；如果您想要更准确的信息，请使用具有更多状态的查找表-几乎没有任何计算。

注意：此处的尺寸仅适用于盘片，与固态硬盘不同-开头/中间/结尾无关紧要

简而言之，我所描述的内容与到目前为止所见的以前的实现之间的主要区别在于，观察磁盘上的文件大小和文件篡改/熵，并使用它来[更多]准确地说明磁盘使用的时间要素。

（该专利留给读者练习...）

当您尝试预测需要花费多长时间时，会有很多“未知”变量。例如，虽然程序知道有3500个文件，并且文件大小为3.5 GB（3500 MB），但这是否意味着每个文件都是1 MB？不必要。可能有很多4 KB文件，很多100 MB文件，以及介于两者之间的其他文件。此外，您还必须考虑文件的来源和去向（例如媒体）。最大的瓶颈是什么？您如何考虑尝试通过VPN隧道从HDD复制文件？您提供一个最佳情况，然后实时调整计数器。这就是为什么您看到那些进度表在动态变化的原因。

数学上正确的模型实际上是进行简单的平均和外推：

transfer speed = data copied / time elapsed
time remaining = data remaining / transfer speed

原因是根据大数定律，局部波动将抵消平均传输速度，这将为您提供最稳定的结果。

微软似乎要做的是计算最近时间的传输速度。这意味着每个局部波动都会显着改变结果。

There is some way to refine or correct this kind of "bug"?

正如Roald van Doorn所说，这基本上只是猜测。当然，这并不意味着它不可能是一个更好的猜测者。有很多启发式方法可用于计算此值。

1. 最好的方法（最昂贵​​的方法）是保留以前“副本”的历史记录，然后使用人工智能算法来计算猜测
2. 可以根据研究需要多长时间来构造一个公式。他们可以考虑以下因素：文件系统，文件数量，文件大小，磁盘查找时间，磁盘批量读/写速度，磁盘上文件的位置（碎片），当前磁盘利用率。
3. 两者混合。就是 做一些基准测试以找出某些运算需要多长时间，然后将其用作简单公式的历史记录。

显然，这些都不容易实现..我只提到文件副本。各种转让都需要做类似的工作。
您必须问自己的问题-是Microsoft宁愿花时间给您一个更好的估计，还是您希望它们使文件传输更快。

但是，如果使用7-zip压缩文件，则会发现猜测比Windows更好。我怀疑它所做的事情很复杂，只是猜测更好一点。

简而言之，该计算基于当前的传输速度。

例如：如果由于Windows必须复制大量的小文件而导致传输速率下降，则对于大文件，预期时间会线性增加，反之亦然。

几乎不可能预测整个传输过程中的传输速度，因为它取决于许多因素，例如文件大小，CPU使用率，传输错误等。

MSDN博客文章“ 改进我们的文件管理基础知识”中有一些有趣的答案：对此进行复制，移动，重命名和删除。至于为什么很难：

几乎不可能以任何精度来估计完成复制所需的时间，因为其中涉及许多不可预测和不可控制的变量–例如，在复制作业的长度上将有多少网络带宽可用？您的防病毒软件会启动并开始扫描文件吗？另一个应用程序需要访问硬盘吗？用户将开始其他复印作业吗？

以及他们如何改善，

与其花费大量时间来得出较低的置信度估计值（该估计值仅会比当前估计值略有改善），我们着重于以有用且引人注目的方式呈现我们有信心的信息。这使我们能够获得最可靠的信息，因此您可以做出更明智的决定。

就是说，如果您真的只想改善给定的估算并保持进度条不变，则可以在Slashdot注释中建议一些建议：

维护文件系统上每个存储设备的预期速度表。记录读取文件系统信息所需的时间。安装设备后，如果设备类型合理，则寻找中间和末端，并在其中测量速度。获取跨位置的读写速度的近似曲线，并将其用于将来的估计。对于将来的读写操作，请记下它们的位置以及走的速度，并相应地调整曲线。

开始操作时，查看各个设备的输入和输出曲线。找到目标位置的预期速度。估计中应使用较低的速度。

只是想补充一下，文件总数很容易成为PC上文件复制操作中最耗时的因素。我永远记得一个年轻的学生，故意从我的计算机班级导致PC失败，方法是从一个没有内容的文件开始，然后复制它，然后选择2个文件并再次复制，依此类推。一旦超过了1024个文件，即使它没有复制任何信息（文件头除外），它也开始花费大量时间来做任何事情。即使在新的操作系统，指数文件副本上自己尝试，也可以看到会发生什么。值得深思。

我刚刚从USB HDD复制了200GB到我的主驱动器。大约有130000个文件

在最初的4-5分钟后，我观察到：

• 对于最小的文件，速度约为每秒100个文件，速度约为600KB / s
• 对于大文件，速度约为70MB / s

开始时，窗口将估算值从1小时更改为5小时以上，然后又更改为1小时，依此类推。最后，例如95％的人仍将估算时间从10分钟更改为10个小时以上。因此，它变得越来越精确，而不是变得越来越精确。

简单的数学表明：

130000页的文件在100个每秒=文件22分钟

200,000 MB，每秒70 MB = 47分钟

22分钟-腾出时间来复制几千字节大小的文件。 47分钟-如果没有查找时间，则需要传输实际数据的时间。

22 分钟+ 47分钟的总和是它可能要花费的绝对最大时间。

所以很明显，估计时间应该在47到69分钟之间。

对话框显示了大约90％的内容：“我正在以1MB / s的速度复制一些小文件，还有20GB的数据，需要5:30个小时才能完成。

几秒钟后：“我正在这里以70mb / s的速度复制一个大文件，需要4分钟才能完成。

人们实际上从同一个对话框中看到的内容：120,000个文件和180GB已被复制40分钟。其余的10000个文件和20GB大约需要5分钟

该对话框提供了足够的信息来进行计算，每秒变得越来越精确。它知道复制小文件的速率。它知道大文件的复制速度。它还知道剩余多少文件和多少字节。

仅通过设置上限和下限来进行如此精确的假设非常简单。

仅当大文件位于小文件之前时，对话框才会显示一些更正确的数据。如果是这种情况，则从40分钟开始，然后在30分钟后开始复制小文件，并说“好，我还需要20分钟”。

但是，当小文件开头和大文件结尾时。该对话框实际上并不关心传输小文件的“每秒文件数”。它像小文件数一样无穷远地进行计算，就像它们永远很小一样。