xkcd

Saya tahu bahwa dialog copy Windows (di Windows XP) menyimpan copy dalam memori terlebih dahulu, dan masih menyalin setelah dialog ditutup, jadi waktunya mati, tetapi mengapa estimasi waktu yang diperlukan untuk membuat salinan sangat tidak akurat, bahkan ketika penyalinan memori telah dinonaktifkan (di Vista dan Windows 7)? Sepertinya sewenang-wenang! Bagaimana cara kerja seluruh prosedur penyalinan, dan mengapa Windows tidak dapat memperkirakannya dengan benar?

Singkatnya: algoritma yang buruk dan estimasi gelisah sebenarnya merupakan kelemahan implementasi.

Alat lain seperti TeraCopy melakukan pekerjaan yang lebih baik. Saya pikir tidak layak menjelaskan mengapa implementasi mereka tidak baik. Mereka akan menyadarinya dan akan meningkat.

Apa yang sulit:

1. Anda harus mempertimbangkan fluktuasi sumber daya akun (terutama kecepatan CPU / Jaringan / HDD)
2. Anda perlu memperkirakan waktu yang diperlukan dengan memprediksi perilaku (apa yang secara definitif tidak dilakukan oleh copy file Windows saat ini).
3. Buat penyesuaian dari waktu ke waktu dengan estimasi awal Anda (maksud saya penyesuaian kecil tidak seperti pada gambar lucu di atas!)

Untuk ini tidak hanya jumlah byte tetapi jumlah file yang dibuat memainkan peran. Jika Anda memiliki sejuta file 1KB atau ribuan file 1MB situasinya akan sangat berbeda karena yang pertama memiliki overhead untuk menciptakan banyak file. Bergantung pada sistem file yang digunakan, ini bisa memakan waktu lebih lama daripada benar-benar mentransfer data.

Dialog ini membuat saya gila juga beberapa kali:

• Pada sistem WinNT yang lebih lama, jika Anda memiliki banyak file kecil untuk disalin, itu menampilkan nama dan animasi yang bagus untuk setiap file memperlambat seluruh proses agar praktis tidak dapat digunakan.

Salinan Windows modern tidak jauh lebih baik:

• Untuk menghitung jumlah data yang akan ditransfer tampaknya membuat pencarian pertama (itulah yang saya kira demikian) sehingga perlu waktu lama jika Anda memilih banyak direktori sampai secara efektif mulai melakukan pekerjaan.
• Beberapa batas waktu bawaan membuat file besar untuk disalin (> sekitar 60GB di sistem saya). Yang menyakitkan adalah ia memberi tahu Anda bahwa setelah menyalin sudah lebih dari 30GB melalui jaringan dan ini kehilangan bandwidth dan waktu karena Anda harus memulai kembali dari awal!
• Salinan file dari satu komputer ke komputer lainnya sangat lambat untuk beberapa alasan. (Maksud saya dibandingkan dengan bandwidth jaringan yang tersedia, menggunakan alat lain lebih cepat sehingga itu bukan batasan komputasi.)

Raymond Chen pernah menulis artikel yang sangat bagus tentang ini. Pada dasarnya, dialog hanya menebak :).

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

"Karena dialog salin hanya menebak. Itu tidak dapat memprediksi masa depan, tetapi dipaksa untuk mencoba. Dan pada awal salinan, ketika ada sedikit sejarah yang berlalu, prediksi itu bisa sangat buruk.

Berikut ini analogi: Misalkan seseorang memberi tahu Anda, "Saya akan menghitung sampai 100, dan Anda perlu memberikan perkiraan terus menerus kapan saya akan selesai." Mereka memulai, "satu, dua, tiga ...". Anda perhatikan mereka akan sekitar satu angka per detik, sehingga Anda memperkirakan 100 detik. Uh-oh, sekarang mereka melambat. "Empat ... ... ... lima ... ..." Sekarang kamu harus mengubah perkiraanmu menjadi mungkin 200 detik. Sekarang mereka mempercepat: "enam-tujuh-delapan-sembilan" Anda harus memperbarui perkiraan Anda lagi.

Sekarang seseorang yang hanya mendengarkan perkiraan Anda dan bukan orang yang menghitung berpikir Anda tidak cocok. Perkiraan Anda berubah dari 100 detik menjadi 200 detik hingga 50 detik; apa masalah Anda? Mengapa Anda tidak bisa memberikan perkiraan yang bagus?

Menyalin file adalah hal yang sama. Shell tahu berapa banyak file dan berapa byte yang akan disalin, tetapi tidak tahu seberapa cepat hard drive atau jaringan atau internet, jadi tinggal menebak saja. Jika copy throughput berubah, estimasi perlu diubah untuk memperhitungkan laju transfer baru. "

Saya akan menghitung sampai sepuluh, 1....2....3....4berapa banyak titik yang diperlukan untuk mencapai 10?

5.6.7Bagaimana dengan sekarang? Apakah Anda memperhitungkan semua titik terakhir antara angka dan rata-rata, apakah Anda hanya mengambil 4 interval terakhir dan menggunakan rata-rata itu, apakah Anda hanya melihat pada interval terakhir?

Anda memiliki masalah yang sama dengan transfer file. Kecepatan transfer file tidak konstan, mempercepat dan memperlambat berdasarkan banyak faktor. Alasan mengapa angka itu melonjak begitu banyak adalah karena Microsoft bersandar pada sisi "hanya menghitung interval terakhir" dari spektrum.

Tidak ada yang salah dengan sisi spektrum itu, ia memberi Anda "detik per detik" yang lebih akurat (satu detik dalam waktu nyata membuat penghitung turun satu detik) tetapi ini menyebabkan ETA total dari pengatur waktu melompat-lompat jauh. .

Contoh yang baik dari sisi yang berlawanan adalah 7-Zip saat dikompresi. Jika kecepatan kompresi turun saat diproses, Anda dapat melihat bahwa ETA tidak melompat secara dramatis seperti transfer file ETA, tetapi mungkin diperlukan 2 hingga 3 detik nyata sebelum timer berdetak satu detik (atau bahkan mungkin mulai menghitung hingga ) sampai stabil pada kecepatan baru.

Sebenarnya ada jawaban yang hampir kanonik oleh Microsoft Raymond Chen tentang ini dari WAAAAAY kembali, dan ada beberapa potongan teka-teki.

Karena dialog salin hanya menebak. Itu tidak dapat memprediksi masa depan, tetapi dipaksa untuk mencoba. Dan di awal salinan, ketika ada sejarah yang sangat sedikit berlalu, prediksi bisa sangat buruk.

Pertama, Windows itu menebak. Ia tahu berapa banyak file, dan seberapa besar mereka, tetapi kecepatan transfer per file sangat bervariasi. Itu tergantung pada hal-hal seperti ukuran, atau bahkan lokasi pada drive dalam beberapa kasus. Seiring berjalannya waktu, ia menyesuaikan perkiraan berdasarkan kondisi saat ini dan masa lalu, dan karenanya Anda memiliki perkiraan kecepatan transfer yang tidak akurat dalam kondisi dunia nyata.

Inilah penjelasan oleh Raymond Chen , Kepala Perancang Perangkat Lunak Utama di Microsoft:

Mengapa dialog salinan memberikan perkiraan yang mengerikan?

Karena dialog salin hanya menebak. Itu tidak dapat memprediksi masa depan, tetapi dipaksa untuk mencoba. Dan di awal salinan, ketika ada sejarah yang sangat sedikit berlalu, prediksi bisa sangat buruk.

Berikut ini analogi: Misalkan seseorang memberi tahu Anda, "Saya akan menghitung sampai 100, dan Anda perlu memberikan perkiraan terus menerus kapan saya akan selesai." Mereka memulai, "satu, dua, tiga ...". Anda perhatikan mereka akan sekitar satu angka per detik, sehingga Anda memperkirakan 100 detik. Uh-oh, sekarang mereka melambat. "Empat ... ... ... lima ... ..." Sekarang kamu harus mengubah perkiraanmu menjadi mungkin 200 detik. Sekarang mereka mempercepat: "enam-tujuh-delapan-sembilan" Anda harus memperbarui perkiraan Anda lagi.

The posting blog yang dikutip di atas memiliki diskusi panjang tentang masalah ini, dengan beberapa komentar yang menarik.

Raymond Chen adalah orang yang legendaris, "Microsoft Chuck Norris", saya kira Anda tidak akan mendapatkan jawaban yang lebih otoritatif. Saya yakin dia setidaknya melihat kode yang dimaksud.

Alasan yang jelas adalah bahwa kecepatan transfer bervariasi dari waktu ke waktu, dan begitu juga rata-rata, dan begitu juga prediksi. Untuk menjelaskan hal ini kepada teman non-teknologi, saya telah menggunakan analogi yang melibatkan perjalanan melalui udara. Anda akan terbang melintasi Atlantik. Ketika Anda tiba dengan taksi di bandara keberangkatan, ETA Anda sekitar dua bulan. Ketika Anda turun di bandara yang tiba, berdasarkan kecepatan rata-rata Anda sejauh ini, Anda akan mencapai rumah teman Anda dalam 5 detik.

Tetapi Anda perlu menghargai seberapa besar kecepatan sebenarnya dapat bervariasi, bahkan dengan apa yang tampak seperti skenario yang dapat diprediksi, seperti menyalin file dalam disk yang sama, atau antara dua disk lokal. Salah satu fitur baru yang saya suka di Windows 8 adalah kemampuan untuk membuat grafik kecepatan dari waktu ke waktu jika Anda mengklik "lebih detail". Jika Anda tidak memiliki akses ke mesin Windows 8, mencari gambar untuk jendela dialog 8 copy untuk banyak contoh. Banyak dari mereka yang rata, tetapi banyak di antaranya juga bergelombang, hingga Anda bertanya-tanya apakah hard drive itu benar-benar sehat, ketika turun ke nol.

Beberapa dari benjolan ini kemungkinan disebabkan oleh variasi dalam ukuran file — bidang yang lebih kecil menghasilkan lebih banyak akses, yang memperlambat segalanya, terutama pada hard drive mekanis yang harus dicari dengan menggerakkan kepala read-nya — tetapi beberapa mungkin hanya berupa drive murah yang kios pada sentuhan sedikit untuk mencegah kerusakan pada piring-piring.

Ada algoritma prediksi ETA yang lebih baik dan lebih buruk, tetapi untuk prediksi yang akurat, komputer harus mengetahui semua hal. Risiko mencoba membuat algoritme "pintar" adalah bahwa hal itu dapat membuat kasus baru yang tidak terduga, yang bahkan lebih salah.

Satu-satunya cara untuk mengetahui berapa lama waktu yang dibutuhkan untuk mengompres satu set file adalah dengan mengompresnya. Terkadang tebakan terbaik Windows sudah dekat, terkadang itu salah besar. Hal yang sama berlaku untuk menyalin sejumlah besar file, karena saya yakin Anda perhatikan.

Ini bukan bug seperti tampilan tidak berguna dari informasi yang jarang akurat. Cara terbaik untuk memperbaikinya adalah dengan menutup mata Anda. Abaikan itu. ;-)

Mungkin ada program di luar sana yang dapat menyalin / memampatkan file dan membuat alarm berbunyi saat selesai. Itu akan sangat berguna. Kita bisa tidur sebentar sambil menunggu Windows menyelesaikan pembersihan rumah.

Saya pikir alasannya dijelaskan dengan baik di salah satu komentar dari posting blog yang ditautkan oleh jawaban Roald:

Ini memiliki algoritma estimasi yang mengerikan. Tidak ada alasan. Jika harus menyalin 1000 file 1KB dan 10 file 1MB menurutnya akan sama sibuknya dengan file 1 MB seperti halnya file 1KB.

Alasan itu memberikan perkiraan yang mengerikan adalah bahwa itu tidak dilakukan dengan baik. Jelas itu tidak pernah bisa 100% tepat tetapi bisa jauh, jauh lebih baik.

Untuk mempercepat proses penyalinan (tidak menghabiskan terlalu banyak waktu untuk menghitung perkiraan waktu alih-alih melakukan operasi yang terkait dengan penyalinan), utilitas penyalinan windows yang dibangun ke dalam Explorer menyimpan sejumlah informasi terbatas tentang seberapa cepat operasi penulisan sebelumnya diselesaikan. Setiap kali perlu menghitung waktu yang tersisa, itu hanya mencari tahu jumlah rata-rata waktu operasi menulis telah diambil, dan kemudian mengalikan dengan jumlah operasi penulisan yang tersisa.

Masalahnya adalah bahwa jumlah waktu yang diperlukan untuk melakukan operasi tulis tidak konstan - sebenarnya dapat sangat bervariasi. Jadi ini, pada gilirannya, menghasilkan perubahan signifikan dalam estimasi waktu.

Ada 3 faktor yang harus dipertimbangkan:

1. Ukuran total transfer.
2. Jumlah file yang akan ditransfer.
3. "Kesibukan" dari media, dan mungkin koneksi.

Angka 1 dan 3 tampaknya memiliki efek paling jelas pada perhitungan waktu transfer, tetapi banyak orang yang tidak memperhitungkan angka 2. Ini dapat memiliki efek besar pada berapa lama transfer akan berlangsung, dan sulit untuk diukur.

Pada dasarnya, setiap kali file ditulis, filesystem perlu menulis sedikit metadata tentang file tersebut, misalnya. kepemilikan, izin, waktu pembuatan / modifikasi / akses, dll. Tergantung pada sistem file tertentu, informasi ini dapat ditulis ke bagian disk yang sangat 'jauh' dari tempat file tersebut sedang ditulis. Overhead filesystem ini adalah apa yang dapat membuat transfer yang tampaknya sederhana membutuhkan waktu lama, dan / atau membuat perkiraan waktu berfluktuasi liar.

misal: Mentransfer satu file besar, Anda akan melihat bahwa perkiraan tersebut stabil dan cukup akurat, tetapi mentransfer ratusan file dengan ukuran yang berbeda-beda, tetapi ukuran total yang sama, dapat memakan waktu lebih lama dan menyebabkan perkiraan waktu cocok.

Ada tiga kekurangan dalam algoritma estimasi saat ini.

Bertentangan dengan kepercayaan populer, mereka hampir tidak cukup sulit untuk mengangkat tangan kita.

Alasan kebanyakan orang menulis blog, dan orang-orang di sini tidak menyadari kemungkinannya adalah yang terbaik yang bisa saya katakan karena bidang studi dan luas sekolah. Obat sederhana namun juga sangat nyaman harus dimungkinkan untuk [lulusan dengan pelatihan yang lebih baru daripada penulis blog] [sebuah perusahaan bernilai miliaran dolar] Microsoft.

Saya akan mencoba menjelaskan mengapa.

Poin-poin kegagalan adalah sebagai berikut. Kernel:

1. tidak dapat secara andal memprediksi pemuatan IO di masa depan karena keadaan di luar lingkup kernel

• tidak ada yang harus dilakukan tentang ini karena ini adalah masalah P = NP yang sangat tidak terbatas.

2. tidak melacak heuristik IO dalam tingkat detail yang berguna. Pemanfaatan adalah konsep yang jauh lebih luas daripada kecepatan baca / tulis disk / jaringan .

• sangat sedikit yang perlu dilakukan mengenai hal ini, sedikit lebih banyak daripada melacak informasi penggunaan IO paling dasar

  • dari disk
    • dimensi kecepatan baca rata-rata 1a
    • kecepatan tulis rata-rata file dimensi 2a
  • berdasarkan per-kuanta * menurut
    • dimensi ukuran file b
    • lokasi file pada dimensi disk c
  • * dikuantisasi menjadi [kemungkinan] tidak lebih dari 3 kategori. Pengurangan dimensi akan membantu kita menentukan secara pasti tetapi 3 harus banyak untuk (mungkin agak efektif) mekanisme prediksi yang lebih baik daripada tidak sama sekali:
    • ukuran file
      • cahaya
      • medium
      • berat
    • lokasi [menginformasikan latensi pencarian]
      • awal
      • tengah
      • Anda mengerti intinya
    • ukuran dan lokasi file berlebihan / tumpang tindih dengan kecepatan baca / tulis, ini disengaja
  • kita perlu tahu seberapa "sibuk" disk tersebut sehingga kita dapat menganggapnya akan terus menjadi dimensi sibuk itu d
    • dihitung dari jumlah file yang sedang dibaca, dililit dengan bobot masing-masing
    • digunakan untuk memperkirakan waktu pada awal penyalinan ... dialog berdasarkan pada muatan yang diharapkan di masa depan jika segala sesuatu selain dari dialog salin ini berlanjut seperti sekarang
  • yang metode pencatatan untuk tujuan ... di sini adalah dipatenkan

3. Apakah mereka dilacak , tidak akan menggunakan heuristik

• sedikit yang telah dilakukan di sini, di mana kita melakukan sebagian besar pekerjaan
• ini adalah tempat kami meletakkan data dari # 2 untuk digunakan
  • analisis statistik kasar dari bobot dan lokasi file untuk menentukan berapa banyak hopping yang akan kita lakukan. Bobot + lokasi memberi kita prediksi
  • bergabung dengan bobot dan lokasi pemuatan disk saat ini
  • untuk memperkirakan apa yang kita pikirkan kecepatan baca / tulis rata-rata dari jumlah dimensi file f akan menjadi
  • yang kami bandingkan dengan menyempurnakan model kami
  • yang akan memungkinkan kami memperkirakan secara akurat bilah kemajuan dan waktu penyelesaian
• yang metode analisis untuk tujuan memprediksi ... di sini adalah dipatenkan

Inti dari semua ini adalah model kami hanya 2a = F * (bxc) + d kompleks

Di mana a, b, dan c masing-masing memiliki 3 status: manajer file mengintip file (atau hanya metadata) sebelum menyalin, dan F * (bxc) + d bukanlah perhitungan yang mahal; jika Anda menginginkan sesuatu yang lebih akurat gunakan tabel pencarian dengan lebih banyak status - hampir tidak ada perhitungan sama sekali.

Catatan: dimensi di sini adalah untuk piring, akan berbeda dengan SSD - awal / tengah / akhir tidak masalah

Perbedaan utama antara apa yang saya jelaskan dan implementasi sebelumnya yang telah kita lihat sejauh ini adalah, singkatnya, mengamati filesize dan file distrubtion / entropy pada disk dan menggunakannya untuk [lebih] memperhitungkan secara akurat elemen waktu penggunaan disk.

(paten dibiarkan sebagai latihan untuk pembaca ...)

Ada banyak variabel "tidak dikenal" ketika Anda mencoba memprediksi berapa lama sesuatu akan terjadi. Misalnya, ketika program mengetahui bahwa ada 3.500 file, dan jumlah file tersebut mencapai 3,5 GB (3.500 MB), apakah itu berarti bahwa setiap file adalah 1 MB? Belum tentu. Mungkin ada banyak file 4 KB, dan banyak file 100 MB, dan beberapa lainnya di antaranya. Selain itu, Anda harus mempertimbangkan dari mana file berasal dan ke mana mereka pergi (misalnya media.) Apa hambatan terbesar? Bagaimana akun Anda mencoba menyalin file dari HDD melalui terowongan VPN ? Anda memberikan skenario kasus terbaik, dan kemudian menyesuaikan penghitung Anda secara real time. Inilah sebabnya mengapa Anda melihat meter kemajuan berubah dengan cepat.

Model yang benar secara matematis adalah benar-benar melakukan rata-rata dan ekstrapolasi yang naif:

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

Alasannya adalah bahwa menurut Hukum Angka Besar fluktuasi lokal akan dibatalkan dalam kecepatan transfer rata-rata , dan ini akan memberi Anda hasil yang paling stabil.

Apa yang tampaknya dilakukan oleh Microsoft adalah menghitung kecepatan transfer pada kerangka waktu terbaru. Ini berarti bahwa setiap fluktuasi lokal mengubah hasilnya secara signifikan.

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

Seperti yang dikatakan Roald van Doorn, pada dasarnya hanya menebak. Tentu saja, itu tidak berarti itu bukan penebak yang lebih baik. Ada banyak heuristik yang dapat digunakan untuk menghitung ini.

1. Cara terbaik, cara termahal, adalah menyimpan riwayat 'salinan' sebelumnya dan kemudian menggunakan algoritma kecerdasan buatan untuk menghitung tebakan
2. Orang bisa membuat formula berdasarkan penelitian berapa lama waktu yang dibutuhkan. Mereka dapat mempertimbangkan hal-hal seperti: sistem file, jumlah file, ukuran file, waktu pencarian disk, kecepatan baca / tulis disk massal, lokasi file pada disk (fragmentasi), pemanfaatan disk saat ini.
3. Campuran keduanya. Yaitu. lakukan beberapa tolok ukur untuk mengetahui berapa lama operasi tertentu berlangsung dan kemudian gunakan itu sebagai sejarah untuk formula sederhana.

Jelas tidak ada yang mudah diimplementasikan .. dan saya hanya menyebutkan salinan file. Pekerjaan serupa perlu dilakukan untuk semua jenis transfer.
Pertanyaan yang harus Anda tanyakan pada diri sendiri - Apakah Anda lebih suka menghabiskan waktu dengan microsoft memberi Anda perkiraan yang lebih baik atau apakah Anda lebih suka mereka membuat transfer file Anda lebih cepat.

Namun, jika Anda mengompres sesuatu dengan 7-zip, Anda akan melihat itu lebih baik daripada menebak daripada windows. Saya ragu itu melakukan sesuatu yang rumit, hanya tebakan yang sedikit lebih baik.

Singkatnya, perhitungan didasarkan pada kecepatan transfer saat ini .

Sebagai contoh: Jika laju transfer Anda tenggelam karena windows harus menyalin sejumlah besar file kecil, waktu yang diharapkan naik secara linear dan sebaliknya untuk file besar.

Hal ini hampir mustahil untuk memprediksi apa kecepatan transfer akan lebih proses transfer secara keseluruhan, karena tergantung pada banyak faktor seperti filesize, penggunaan CPU, transmisi erros dll

Ada beberapa jawaban menarik di posting blog MSDN. Memperbaiki dasar-dasar manajemen file kami: salin, pindahkan, ganti nama, dan hapus tentang ini. Mengapa ini sulit:

Memperkirakan waktu yang tersisa untuk menyelesaikan salinan hampir tidak mungkin dilakukan dengan presisi apa pun karena ada banyak variabel tak terduga dan tak terkendali yang terlibat - misalnya, berapa banyak bandwidth jaringan yang akan tersedia untuk panjang pekerjaan penyalinan? Apakah perangkat lunak anti-virus Anda berputar dan mulai memindai file? Apakah aplikasi lain perlu mengakses hard drive? Apakah pengguna akan memulai pekerjaan salin lain?

Dan bagaimana mereka membaik,

Daripada menginvestasikan banyak waktu untuk menghasilkan estimasi kepercayaan rendah yang hanya akan sedikit meningkat dibandingkan yang sekarang, kami berfokus pada penyajian informasi yang kami yakini dengan cara yang bermanfaat dan menarik. Ini membuat informasi yang paling andal yang kami miliki tersedia untuk Anda sehingga Anda dapat membuat keputusan yang lebih tepat.

Yang mengatakan, jika Anda benar-benar ingin meningkatkan hanya perkiraan yang diberikan dan mempertahankan progress bar seperti apa adanya, Anda bisa melakukan sesuatu yang disarankan dalam komentar Slashdot :

Pertahankan tabel kecepatan yang diharapkan untuk setiap perangkat penyimpanan di sistem file. Catat berapa lama untuk membaca informasi sistem file. Ketika sebuah perangkat dipasang, jika masuk akal untuk jenis perangkat, mencari ke tengah dan akhir, mengukur kecepatan di sana juga. Dapatkan perkiraan kurva untuk kecepatan baca dan tulis di seluruh lokasi, dan gunakan kurva itu untuk taksiran mendatang. Untuk operasi baca dan tulis di masa mendatang, catat di mana mereka berada dan seberapa cepat mereka pergi, dan sesuaikan kurva sesuai.

Ketika operasi dimulai, lihat kurva untuk input dan output untuk masing-masing perangkat. Temukan kecepatan yang diharapkan untuk lokasi target. Kecepatan mana yang lebih rendah harus digunakan untuk estimasi.

Hanya ingin menambahkan bahwa jumlah total file dengan mudah merupakan faktor yang paling memakan waktu dari operasi penyalinan file pada PC. Saya selalu ingat sebagai seorang siswa muda, yang dengan sengaja menginduksi kegagalan PC di kelas komputer saya dengan memulai dengan 1 file tanpa isi, dan menyalinnya, lalu memilih 2 file dan menyalin lagi dan seterusnya. Setelah melewati sekitar 1024 file itu mulai mengambil sejumlah besar waktu untuk melakukan apa pun bahkan ketika sedang menyalin tidak ada informasi yang disimpan untuk header file. Cobalah sendiri bahkan di OS baru, salin file eksponensial dan Anda akan melihat apa yang terjadi. Bahan untuk dipikirkan.

Saya baru saja menyalin 200GB dari USB HDD ke drive utama saya. Ada sekitar 130000 file

Setelah 4-5 menit pertama saya mengamati bahwa:

• Untuk file terkecil, kecepatannya sekitar 100 file per detik sekitar 600KB / s
• Dan untuk file besar rasanya seperti 70MB / s

Pada awalnya windows mengubah estimasi dari seperti 1 jam menjadi 5+ jam lalu kembali ke 1 jam dan seterusnya. Pada akhirnya seperti pada 95% itu masih mengubah estimasi dari 10 menit menjadi 10+ jam. Jadi, alih-alih menjadi lebih akurat, itu menjadi kurang dan kurang tepat.

Pertunjukan matematika sederhana:

130.000 file dengan 100 file per detik = 22 menit

200.000 MB pada 70 MB per detik = 47 menit

22 menit - kehilangan waktu menyalin file beberapa kilobyte. 47 menit - waktu yang diperlukan untuk mentransfer data aktual jika tidak ada waktu pencarian.

Jumlah 22 menit + 47 menit adalah waktu maksimum absolut yang mungkin diperlukan.

Jadi jelas perkiraannya harus antara 47 dan 69 menit.

Apa dialog menunjukkan sekitar 90%: "Saya menyalin beberapa file kecil pada 1MB / s, ada 20GB lebih banyak data, akan dibutuhkan 5:30 jam untuk menyelesaikan.

Beberapa detik kemudian: "Saya menyalin file besar di sini, pada 70mb / s akan membutuhkan waktu 4 menit untuk selesai.

Apa yang sebenarnya dilihat manusia dari dialog yang sama: 120.000 file dan 180GB sudah disalin selama 40 menit. Sisanya, 10.000 file dan 20GB akan memakan waktu sekitar 5 menit

Dialog memberikan informasi yang cukup untuk membuat perhitungan yang semakin akurat setiap detik. Ia tahu tingkat di mana file kecil disalin. Ia tahu pada kecepatan berapa file-file besar disalin. Ia juga tahu berapa banyak file dan berapa byte yang tersisa.

Sangat sederhana untuk membuat asumsi yang begitu akurat hanya dengan menetapkan batas atas dan bawah.

Dialog menunjukkan data yang sedikit lebih benar hanya dalam kasus ketika file besar ada sebelum file kecil. Jika ini masalahnya dimulai pada 40 menit, dan setelah 30 menit mulai menyalin file kecil dan berkata "baik saya perlu 20 menit lagi".

Tetapi ketika file kecil di awal dan file besar di akhir. Dialog sebenarnya tidak peduli pada "file per detik" apa yang ditransfernya file-file kecil. Itu membuat perhitungannya seperti jumlah file kecil tak terhingga, dan seperti mereka akan selamanya kecil.