Windowsのコピーダイアログ（Windows XPでは）が最初にメモリにコピーを保存していて、ダイアログが閉じた後もコピーをしているので時間がずれているのは知っているのですが、メモリコピーが無効になっているのに（VistaやWindows 7では）、なぜコピーにかかる時間の見積もりがあんなに不正確なのでしょうか？恣意的としか思えない!コピーの手順全体はどうなっているのか、なぜWindowsはそれを正しく見積もることができないのか
41 Maxim Zaslavsky 2009-09-18
要するに、アルゴリズムの貧弱さと飛びぬけた推定は、実は実装上の弱点なのです
TeraCopyのような他のツールは、より良い仕事をします。私は、彼らの実装が良くない理由を説明する価値はないと思います。彼らはそれに気づいているでしょうし、改善するでしょう
難しいこと
- リソースの変動（主にCPU/ネットワーク帯域/HDDの速度）を考慮しなければなりません
- 行動を予測して時間を外挿する必要があります（Windowsのファイルコピーが今決定的に悪いことをしているもの）
- あなたの元の推定に時間をかけて調整を行います（私は上の面白い写真のような小さな調整を意味します！）
このためには、バイト数だけでなく、作成するファイルの量も重要な役割を果たします。100万個の1KBファイルがある場合と、1000個の1MBファイルがある場合では、前者の方が多くのファイルを作成するオーバーヘッドがあるため、状況は大きく異なります。使用するファイルシステムによっては、実際にデータを転送するよりも時間がかかる場合があります
この台詞にも何度かイラッとさせられました
- 古いWinNTシステムでは、コピーする小さなファイルがたくさんあると、各ファイルの名前とアニメーションが表示され、プロセス全体の速度が遅くなり、実質的に使用できなくなっていました
最近のWindowsのコピー物はあまり良くないですね
- 転送するデータ量を計算するには、最初にルックアップを行うようです（それは私が推測していることです）ので、多くのディレクトリを選択する場合は、それが効果的に仕事を開始するまで、それは年齢がかかります
- いくつかの組み込みのタイムアウトはコピーされる大きなファイルを弾劾します（私のシステムでは60GB以上）。痛みは、ネットワーク経由ですでに30GB以上コピーした後に、あなたがゼロから再起動する必要があるため、これはバンド幅と時間を失っていることを教えてくれることです!
- あるコンピュータから別のコンピュータへのファイルのコピーは、なぜかとても遅いです。(利用可能なネットワーク帯域幅と比較して、他のツールを使用した方が速いので、計算上の制限ではありません)
29 jdehaan 2009-09-18
Raymond Chenさんが以前、とても素敵な記事を書いていました。基本的に台詞は推測でしかありません 🙂
“コピーダイアログは推測に過ぎないから未来を予測することはできないが、無理矢理にでもやってみる。そして、コピーの最初の方、歴史がほとんどないときには、予測が本当に悪くなることがあります
例え話をしよう誰かに言われたとしましょう 「100まで数えるから いつ終わるか連続的に見積もってくれ」と彼らは、「１、２、３…」と言い始めます。彼らは1秒に1つの数字でやっていることに気づくので、100秒と見積もってください。おやおや、今、彼らは遅くなっている。”4…５…５…推定値を200秒に変更してください今、彼らはスピードを上げています”6-7-8-9″ 再度見積もりを更新してください
今、あなたの見積もりだけを聞いていて、カウントしている人ではなく、あなたの見積もりを聞いている人は、あなたがおかしくなっていると思っています。あなたの見積もりは100秒→200秒→50秒になりました。なぜ良い見積もりができないのですか？
ファイルのコピーも同じです。シェルは何個のファイルが何バイトコピーされるかを知っていますが、ハードドライブやネットワーク、インターネットの速度を知らないので、推測するしかありません。コピースループットが変化した場合は、新しい転送速度を考慮して推定値を変更する必要があります。”
48 R-D 2012-01-04
10まで数えようとしているのですが、1....2....3....410になるには何ドット必要なのでしょうか？
5.6.7 今はどうですか？数字の間の過去の点をすべて考慮に入れて平均化するのか、最後の4つの間隔だけを取ってその平均値を使うのか、最後の間隔だけを見るのか
ファイル転送でも同じ問題を抱えていますね。ファイルの転送速度は一定ではなく、多くの要因に基づいてスピードアップしたり遅くなったりします。数がそんなに周りにジャンプする理由は、マイクロソフトがスペクトルの “最後の間隔だけをカウントする “側に傾いているからです
スペクトルのそちら側には何も問題はありませんが、それはあなたにより正確な “秒当たりの秒 “を与えます（リアルタイムでは1秒でカウンタが1秒下がるようになります）が、これは、タイマーの合計ETAが多くの周りにジャンプする原因となります
反対側の良い例としては、圧縮しているときの7-Zipがあります。それが処理するように圧縮の速度が低下した場合、ファイル転送のETAのように劇的にはジャンプしないことがわかりますが、それはそれが新しい速度で安定するまで、タイマーが1秒を刻む（またはそれがカウントアップを開始することもあります）1秒前に2〜3の実際の秒がかかることがあります
33 Scott Chamberlain 2014-02-01
実際には、MicrosoftのRaymond Chenによるこの件についての正典的な回答がずっと前からあり、パズルにはいくつかのピースがあります
なぜなら、コピーダイアログは推測に過ぎないからです。未来を予測することはできないが、無理矢理にでもやってみる。そして、コピーの最初の方、履歴がほとんど残っていないときには、予測が本当に悪くなることがあります
まず、Windowsが推測していること。ファイルの数や大きさは分かっていますが、1ファイルあたりの転送速度は非常に変動します。サイズや、場合によってはドライブ上の位置などにも依存します。時間が経つにつれて、現在と過去の状況に基づいて推測を調整しているため、現実世界の状況下での転送速度を不正確に見積もってしまうのです
15 Journeyman Geek 2014-02-01
ここでは、マイクロソフトの主席ソフトウェア設計エンジニアであるレイモンド・チェンによる解説を紹介します
コピーダイアログはなぜあんなにひどい見積もりを出してくるのでしょうか？
なぜなら、コピーダイアログは推測に過ぎないからです。未来を予測することはできないが、無理矢理にでもやってみる。そして、コピーの最初の方、履歴がほとんど残っていないときには、予測が本当に悪くなることがあります
例え話をしよう誰かに言われたとしましょう 「100まで数えるから いつ終わるか連続的に見積もってくれ」と彼らは、「１、２、３…」と言い始めます。彼らは1秒に1つの数字でやっていることに気づくので、100秒と見積もってください。おやおや、今、彼らは遅くなっている。”4…５…５…推定値を200秒に変更してください今、彼らはスピードを上げています”6-7-8-9″ 再度見積もりを更新してください
上で引用したブログ記事には、この問題についての長い議論があり、いくつかの興味深いコメントがあります
レイモンド・チェンは「マイクロソフトのチャック・ノリス」という伝説の人物ですが、これ以上の権威ある回答はないでしょうね。彼は少なくとも問題のコードを見たことがあるはずだ
12 haimg 2011-10-18
明らかな理由は、転送の速度が時間の経過とともに変化し、平均値も変化し、予測も変化するからです。技術者ではない友人にこのことを説明するために、私は飛行機での旅行を例えてみました。あなたは大西洋の上空を飛ぶことになります。出発空港にタクシーで到着したときのETAは約2ヶ月です。到着した空港で降りるとき、これまでの平均速度に基づいて、あなたは5秒で友人の家に到着します
しかし、同じディスク内のファイルをコピーしたり、2つのローカルディスク間でファイルをコピーしたりと、予測可能なシナリオのように思えるものでも、実際には速度がどれだけ変わるかを評価する必要があります。私が気に入っているWindows 8の新機能の1つは、「詳細」をクリックすると、時間経過とともに速度をグラフ化できる機能です。Windows 8のマシンにアクセスできない場合は、Windows 8のコピーダイアログで画像を検索すると、たくさんの例が出てきます。その多くは、かなりフラットなものが多いのですが、ゼロにまで落ち込んだときに、ハードドライブが本当に健全なのかと疑問に思うほど、不穏なデコボコも多いのです
これらのバンプのいくつかは、ファイルサイズの違いによるものと思われます。小さいフィールドはより多くのアクセスをもたらし、特に読み取りヘッドを動かしてシークしなければならない機械的なハードドライブでは、物事が遅くなります
ETAの予測アルゴリズムには良いものと悪いものがありますが、正確な予測をするためには、コンピュータは全知全能でなければなりません。アルゴリズムを「スマート」にしようとすることのリスクは、それがさらにおかしなことに間違っているという不測の事態を新たに生み出す可能性があるということです
9 nitro2k01 2014-02-01
ファイルのセットを圧縮するのにどれくらいの時間がかかるかを知る唯一の方法は、ファイルを圧縮することです。Windows の最良の推測が近いこともあれば、大きく間違っていることもあります。お気づきだと思いますが、大量のファイルをコピーするときも同じです
滅多に正確な情報が表示されないので、バグというよりも無駄な表示になってしまいます。直すには目を閉じるのが一番です。無視してください。)
おそらく、ファイルをコピー/圧縮し、それが終了したときにアラーム音を鳴らすことができるプログラムがそこにあります。それは本当に便利ですね。Windowsがハウスクリーニングを終えるのを待つ間、少し昼寝をすることができます
4 Steve Rindsberg 2012-01-04
その理由は、ロアルドさんの回答でリンクされているブログ記事のコメントの中の一つにうまく説明されていたと思います
恐ろしい推定アルゴリズムを持っています。言い訳はできません。1000個の1KBファイルと10個の1MBファイルをコピーしなければならない場合は、1KBファイルと同じように1MBファイルで忙しくなると考えています
そのような恐ろしい見積もりを与える理由は、それがよく行われていないからです。明らかに100%の正確さはありえませんが、それははるかに、はるかに良いかもしれません
4 Thomas Bonini 2012-01-04
コピー処理を迅速化するために（コピー関連の操作を行う代わりに時間の見積もりを計算するのに時間をかけすぎないように）、エクスプローラーに組み込まれているwindowsコピーユーティリティは、以前の書き込み操作がどのくらいの速さで完了したかについての限られた情報を保持しています。残り時間の計算が必要になるたびに、書き込み操作にかかった平均時間を計算し、残りの書き込み操作の数を掛け合わせています
問題は、書き込み操作を実行するのにかかる時間は一定ではなく、実際には大きく変化する可能性があるということです。そのため、時間の見積もりに大きな変化が生じます
4 Brian Gradin 2014-02-01
考慮すべき3つの要素があります
- 振込の合計サイズです
- 転送するファイル数です
- メディアの「忙しさ」と、もしかしたら繋がりがあるかもしれません
1番と3番は振込時間の計算に最も分かりやすい影響があるように思えますが、2番を考慮していない人が非常に多いです。これは、転送にかかる時間に大きな影響を与える可能性があり、定量化することは困難です
基本的に、ファイルが書き込まれるたびに、ファイルシステムはファイルの所有権、パーミッション、作成/変更/アクセス時間などのメタデータを書き込む必要があります。特定のファイルシステムにもよりますが、この情報はファイルが書き込まれる場所から「遠く離れた」ディスクの一部に書き込まれることがあります。このファイルシステムのオーバーヘッドは、一見簡単そうに見える転送に長い時間がかかったり、時間の見積もりが乱高下したりすることがあります
例：1つの大きなファイルを転送すると、見積もりが安定しており、かなり正確であることに気づくでしょうが、さまざまなサイズのファイルを転送しても、合計サイズは同じですが、何百ものファイルを転送すると、時間がかかり、時間の見積もりが合わなくなる可能性があります
4 Sammitch 2014-02-01
現在の推定アルゴリズムには3つの欠陥があります
一般的な信念に反して、彼らは私たちの手を投げ出すほど難しくはありません
ブログを書いている人やここにいる人のほとんどがその可能性に気付いていないのは、私の知る限りでは、勉強の分野や学校の幅の広さに起因しています。控えめでありながらも、非常に快適な救済策は、[ブログライターよりも最近の訓練を受けた卒業生] [数十億ドルの企業]マイクロソフトのために可能であるべきです
その理由を大まかに説明しようと思います
故障のポイントは以下の通りです。カーネルです
1. カーネルの範囲外の状況のため、将来の IO 負荷を確実に予測できない
- これは非常に束縛されていないP=NPの問題なので、何もすべきではありません
2.IO ヒューリスティックを追跡することはできません。利用率は、ディスク/ネットワークの読み書き速度よりもはるかに広い概念です
これについてはほとんど何もする必要がなく、最も基本的な IO 使用情報を追跡するだけです
- ディスクから
- 平均読み取り速度次元１ａ
- ファイル次元２ａの平均書き込み速度
- に基づき、1 クアンタ*あたりで計算します
- ファイルのサイズ寸法 b
- ディスクの次元 c 上のファイルの位置を指定します
- *3つ以上のカテゴリに[おそらく]量子化されていません。次元削減は、私たちが確かなことを決定するのに役立つだろうが、（おそらくむしろ効果的な）何よりも優れた予測メカニズムのためには、3つで十分であるべきである：
- ファイルサイズ
- light
- medium
- heavy
- location [シーク待ち時間を通知]
- beginning
- middle
- 言いたいことはわかる
- ファイルのサイズと場所が冗長になっている/読み書き速度と重なっている、これは意図的なものです
- ファイルサイズ
- ディスクがどの程度 “ビジー “であるかを知る必要があります
- 読み込まれたファイルの量から計算され、それぞれの重み付けが行われます
- コピー開始時の時間を推定するために使用されます…ダイアログは、このコピーダイアログ以外のすべてのものが現在のまま継続されている場合、将来の予想される負荷に基づいています
- 目的のために記録する方法は特許があります
- ディスクから
彼らが追跡されていたなら ヒューリスティックスを使わないだろう
- ここでは、ほとんどの作業が行われていません
- ここに#2のデータを入れて使用します
- ファイルの重みと位置を大まかに統計的に分析して、どの程度のホッピングを行うかを決定します。重み＋位置から予測が得られます
- 現在のディスク負荷の重さと位置を組み合わせます
- 次元fのファイル数の平均的な読み取り/書き込み速度は何になると思うかを推定します
- このモデルを微調整するために比較しています
- これにより、プログレスバーと完成までの時間を非常に正確に見積もることができます
- 予測を目的とした分析方法は…ここに特許があります
ここでのポイントは、私たちのモデルは、2a = F*(b x c) + d 複素数でしかありません
a, b, および c はそれぞれ 3 つの状態を持っています: ファイルマネージャはコピーする前にファイル (またはメタデータだけ) を覗き見ますし、F*(b x c) + d は高価な計算ではありません
注意: ここでの寸法は大皿のためのものであり、SSDでは異なるでしょう — 最初/真ん中/最後は重要ではありません
私が説明したことと、これまで見てきた以前の実装との重要な違いは、簡単に言えば、ディスク上のファイルサイズとファイルの乱れ/エントロピーを観察し、それを使ってディスク使用量の時間要素を[より正確に]説明することです
(特許は読者のための演習として残していますが…)
4 paIncrease 2014-11-29
何かにかかる時間を予測しようとするとき、多くの「未知の」変数があります。例えば、プログラムが3500個のファイルがあり、そのファイルの容量は3.5 GB (3500 MB)であることを知っていても、各ファイルは1 MBであることを意味するのでしょうか？必ずしもそうとは限りません。4 KB のファイルがたくさんあっても、100 MB のファイルがたくさんあっても、その間のいくつかのファイルがあっても構いません。また、ファイルがどこから来てどこに行くのか（メディアなど）を考慮しなければなりません。VPN トンネルを介して HDD からファイルをコピーしようとした場合、どのように考慮しますか?あなたはベストケースのシナリオを与え、その後、リアルタイムでカウンタを調整します。これが、プログレスメーターがその場で変化するのを見る理由です
3 JSanchez 2014-02-01
数学的に正しいモデルは、実際にナイーブな平均化と外挿を行うことです
transfer speed = data copied / time elapsed
time remaining = data remaining / transfer speed
大数の法則により、局所的なゆらぎが平均化された転送速度で相殺され、最も安定した結果が得られるからです
マイクロソフトがやっているようなのは、最新の時間枠で転送速度を計算しているようです。つまり、局所的な変動ごとに結果が大きく変わるということです
2 ybungalobill 2012-05-11
There is some way to refine or correct this kind of "bug"?
ロアルド・ヴァン・ドォーンが言っていたように、基本的にはただの推測です。もちろん、だからといって、それ以上の推測ができないわけではありません。これを計算するのに使えるヒューリスティックはいくらでもある
- 最も良い方法、最も高価な方法は、過去の「コピー」の履歴を残しておき、人工知能アルゴリズムを使って推測を計算することです
- 人は、それがどのくらいかかるかの研究に基づいて式を構築することができます。ファイルシステム、ファイル数、ファイルサイズ、ディスクシーク時間、ディスクの一括読み取り/書き込み速度、ディスク上のファイルの位置(断片化)、現在のディスク利用率などを考慮に入れることができます
- この2つをミックスしたものです。例えば、ある操作にどれくらいの時間がかかるかを調べるためにベンチマークを行い、それを単純な数式の履歴として使用します
明らかにどれも簡単には実装されていません。同様の作業は、すべての種類の転送のために行われる必要があります。 あなたが自分自身に尋ねなければならない質問 – あなたはむしろマイクロソフトがあなたにより良い見積もりを与えるためにそれの時間を費やすか、彼らがあなたのファイルの転送を高速化したいと思いますか？
しかし、7-zipで何かを圧縮すると、windowsよりも推測としてははるかに優れていることに気づくでしょう。私はそれがそんなに複雑なことをしているのかと疑っています
1 user606723 2012-01-04
要するに、電流の伝達速度に基づいて計算しているのです
例えばWindowsが大量の小さなファイルをコピーしなければならないため、転送速度が沈む場合、期待される時間は直線的に増加し、大きなファイルの場合はその逆になります
転送速度は、ファイルサイズ、CPU使用率、転送エラーなどの多くの要因に依存するため、全体の転送速度を予測することはほぼ不可能です
1 klingt.net 2014-02-01
これについては、MSDNのブログ記事ファイル管理の基本：コピー、移動、リネーム、削除に興味深い回答があります。なぜ難しいのかについて
コピーが完了するまでの残り時間を見積もることは、予測不可能で制御できない変数が多く存在するため、正確に見積もることはほぼ不可能です。アンチウィルスソフトが起動してファイルのスキャンを開始するか？別のアプリケーションがハードドライブにアクセスする必要がありますか？ユーザーは別のコピージョブを開始しますか？
そして、どのように改善しているのか、、、
私たちは、現在のものよりもわずかに改善されるだけの信頼性の低い見積もりを出すことに多くの時間を費やすのではなく、私たちが自信を持っている情報を有益で説得力のある方法で提示することに重点を置きました。これにより、私たちが持っている最も信頼性の高い情報を利用できるようになり、より多くの情報に基づいた意思決定を行うことができるようになりました
つまり、あなたが本当に与えられた見積もりだけを改善し、それがそのままプログレスバーを維持したい場合は、a Slashdotのコメントで示唆された何かを行うことができました
ファイルシステム上の各ストレージデバイスの予想速度の表を保持する。ファイルシステムの情報を読み取るのにかかる時間を記録する。デバイスがマウントされているときに、デバイスの種類が妥当であれば、真ん中と端を探して、そこでも速度を測定する。場所をまたいで読み書き速度の近似曲線を取得し、将来の推定に使用する。将来の読み取りと書き込み操作のために、それらがどこにあるか、どのくらいの速度で移動するかをメモしておき、それに応じてカーブを調整します
運転を開始したら、それぞれのデバイスの入出力カーブを見てください。目標とする場所の予想速度を求めます。どちらか低い方の速度が推定に使用されるべきです
1 eis 2012-01-04
ただ付け加えておきたいのは、PCでのファイルコピー作業の中で、ファイルの総数が最も時間を消費する要因になりやすいということです。私は若い学生の頃、コンピュータの授業で、内容のない1つのファイルから始めてコピーし、2つのファイルを選択して再度コピーするなどして、わざとPCの故障を誘発していたことをいつも覚えています。それが1024ファイルくらいになると、ファイルヘッダのために何も情報を保存しないでコピーしていても、何をするにも膨大な時間がかかるようになりました。新しいOSでも自分で試してみて、指数関数的にファイルをコピーするとどうなるか見てみましょう。思考の糧になる
1 daft gowk 2016-01-08
先ほどUSB HDDからメインドライブに200GBコピーしました。130000くらいのファイルがありました
最初の4-5分後に私はそれを観察しました
- 一番小さいファイルでは、600KB/s程度で1秒間に100ファイル程度の速度でした
- そして、大きなファイルの場合は70MB/sという感じでした
最初のウィンドウでは、1時間から5時間以上に変更され、その後1時間に戻ったりしていました。最後の方では95%の確率で10分から10時間以上に変化していました。そのため、より正確になるどころか、どんどん正確さを失っていきました
単純な数学が示している
100ファイル/秒＝22分で13万ファイル
70MB/秒＝47分で20万MB
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分必要です」と表示されます
しかし、小さなファイルが先頭にあり、大きなファイルが最後にある場合。ダイアログは、小さなファイルを転送する際に、どのくらいの「秒当たりのファイル数」で転送するかを気にしません。小さなファイルの数は無限大であるかのように計算されていて、永遠に小さなファイルであるかのように計算されています
0 Xizario 2016-07-29
