16,472
社区成员
发帖
与我相关
我的任务
分享如何计算文件复制的时间
目前我使用的公式是：
剩余的时间＝（总文件大小－已复制文件的大小）/(已复制文件大小/已用时)
有什么更好的算法。
剩余的时间＝（总文件大小－已复制文件的大小）/(已复制文件大小/已用时)
有什么更好的算法。
...全文
请发表友善的回复…
发表回复
鄢老 2010-09-26
- 打赏
- 举报
楼主的算法还要修改下,最好是:
剩余的时间＝(double)(（总文件大小－已复制文件的大小）*已用时)/(double)(已复制文件大小)
这样更精确些
剩余的时间＝(double)(（总文件大小－已复制文件的大小）*已用时)/(double)(已复制文件大小)
这样更精确些
xiaohuh421 2010-09-26
- 打赏
- 举报
[Quote=引用 10 楼 gis050208 的回复:]
复制不是下载哦！！
[/Quote]
复制的时候,当CPU被其它程序占用很多,这有DMA就会很慢,这个时候就和下载东西原理差不多了.你总不能说你CPU一直都0%吧,你多复制几个文件的时候cpu一样很高.
复制不是下载哦！！
[/Quote]
复制的时候,当CPU被其它程序占用很多,这有DMA就会很慢,这个时候就和下载东西原理差不多了.你总不能说你CPU一直都0%吧,你多复制几个文件的时候cpu一样很高.
tempzjut 2010-09-26
- 打赏
- 举报
剩余量除当前速度(最近小时间内复制量/时间)
大V雪 2010-09-26
- 打赏
- 举报
复制不是下载哦！！
jackson35296 2010-09-25
- 打赏
- 举报
我做过不少类似的，LZ那样算的话不太准确，因为是按平均速度计算的剩余时间。假如开始传得很慢，后来传得很快，那么实际剩余时间应该除以后来的速度，除以平均速度的话，剩余时间比实际的长。我的做法是用GetTickCount精确计时，计算当前时间点前2秒内的平均速度，作为瞬时速度，然后估计以后的剩余时间。这样是比较准确的，字节/毫秒，再转换为字节/秒，千万不要直接用字节除以秒。
再举个简单的例子说明LZ那个公式不可取的地方。假如你用迅雷下一个1G的文件，开始的900MB都十分顺利，平均速度1M/S，还剩100MB，这时网速突然爆卡，实际速度10K/S，剩余时间还有100M/10k 约等于 10000S。但是如果你算平均速度，速度可能还有0.5M/s，这样剩余时间100M/0.5M约等于200S。因此偏差是十分大的。正确做法应该是用剩余大小除以前n秒的平均速度，这个n可以自己确定，个人认为2-3秒最合适，但是一定要除以毫秒之后再换算成秒。
再举个简单的例子说明LZ那个公式不可取的地方。假如你用迅雷下一个1G的文件，开始的900MB都十分顺利，平均速度1M/S，还剩100MB，这时网速突然爆卡，实际速度10K/S，剩余时间还有100M/10k 约等于 10000S。但是如果你算平均速度，速度可能还有0.5M/s，这样剩余时间100M/0.5M约等于200S。因此偏差是十分大的。正确做法应该是用剩余大小除以前n秒的平均速度，这个n可以自己确定，个人认为2-3秒最合适，但是一定要除以毫秒之后再换算成秒。
傻X 2010-09-25
- 打赏
- 举报
本身就没有绝对准确的计算方法，微软的OS，同一硬盘拖拽文件进不同分区，也会因为你启动其他程序而更改你的剩余时间。不必太执着。
zyrr159487 2010-09-25
- 打赏
- 举报
剩余的时间＝总文件大小 /复制速度－已用时
zgsdzhaolanxiang1 2010-09-25
- 打赏
- 举报
mark 之。。。
cwj2009 2010-09-25
- 打赏
- 举报
感觉你的算法已经很好了
ponydph 2010-09-25
- 打赏
- 举报
时间计算出来也不一定准确，经常变化的
ls2141 2010-09-25
- 打赏
- 举报
so..差不多就行了呗
muzizongheng 2010-09-25
- 打赏
- 举报
一般都是估算， 没有什么精确的api
珍惜生命远离CPP 2010-09-25
- 打赏
- 举报
没，MS自带的也差不多是这么算的
