【发布时间】:2014-03-19 18:37:03
【问题描述】:
我有一个应用程序可以通过网络将大量文件复制到文件服务器(不是网络)。我正在尝试显示对剩余时间的一半体面估计。
我查看了许多关于 SO 的文章,但问题得到了解决,但我没有尝试真正做我想做的事。我希望估计的剩余时间相对稳定。不要根据波动的传输速度到处乱跳。
所以我看到的第一个解决方案是以每秒字节数为单位计算传输速度
double bytePerSec = totalBytesCopied / TimeTaken.TotalSeconds;
然后将剩余的总字节数除以传输速率。
double secRemain = (totalFileSizeToCopy - totalBytesCopied) / bytePerSec;
我认为一旦复制了几 MB,剩余的时间会变得更加稳定(尽管预计它会改变。它没有,它不稳定并且到处乱跳。
然后我在 SO.... 上尝试了其中一种解决方案。
double secRemain = (TimeTaken.TotalSeconds / totalBytesCopied) * (totalFileSizeToCopy - totalBytesCopied);
这是一个类似的计算,但希望它可能会有所作为!
所以现在我有点想我需要从不同的角度来解决这个问题。 IE 使用平均值?使用某种倒数计时器并每隔一段时间重新设置一次时间?只是寻找已经遇到此问题的任何人的意见或最好的建议。
【问题讨论】:
-
您可能还想考虑每个文件可能带有每个文件的延迟时间 - 用于打开流并在某处创建新文件。复制一百万个 1kB 文件会比复制一个 1 GB 文件花费更长的时间吗?
-
您是否可以显示带有“正在复制 XXX 的 1 个”的进度条?
-
link 这是你可能想要的。
-
@ShellShock 绝对是的,但必须有一种方法来计算并稳定结果,以便粗略估计总传输需要多长时间。
-
假设您的网络硬件在您开始传输时已经处于最大负载下,并且公式表明完成文件传输需要 2 小时。现在,在前 10 分钟之后,占用您资源的进程退出了,看起来您的文件传输的其余部分只需要 5 分钟。您希望计时器指示什么?在文件传输 20、30、40... 分钟内重复相同的思维实验。
标签: c# math file-copying