xkcd

Я знаю, що діалогове вікно копіювання Windows (у Windows XP) спочатку зберігає копію в пам’яті, і вона все ще копіюється після закриття діалогового вікна, тому час вимкнено, але чому оцінюється час, який знадобиться для створення копії настільки неточні, навіть коли копіювання пам'яті було вимкнено (у Vista та Windows 7)? Це здається таким довільним! Як працює вся процедура копіювання і чому Windows не може її оцінити правильно?

Коротше кажучи: погані алгоритми та нестримне оцінювання насправді є слабкістю в реалізації.

Інші інструменти, такі як TeraCopy, роблять кращу роботу. Я вважаю, що не варто пояснювати, чому їх виконання не добре. Вони це помітять і покращать.

Що важко:

1. Ви повинні враховувати коливання ресурсів (в основному пропускна здатність процесора / мережі / швидкість жорсткого диска)
2. Вам потрібно екстраполювати час, який знадобиться, передбачивши поведінку (те, що копія файлів Windows остаточно робить погано зараз).
3. З часом вносьте коригування до своєї первісної оцінки (я маю на увазі невеликі коригування, не такі, як на смішній картинці вище!)

Для цього не тільки кількість байтів, але й кількість файлів, які потрібно створити. Якщо у вас є мільйон файлів розміром 1 КБ або тисяча файлів в розмірі 1 МБ, ситуація буде зовсім іншою, оскільки перший має накладні витрати на створення безлічі файлів. Залежно від використовуваної файлової системи, це може зайняти більше часу, ніж фактично передача даних.

Цей діалог також зводив мене з розуму досить багато разів:

• У старих системах WinNT, якщо у вас було багато невеликих файлів для копіювання, вона відображала ім'я та приємну анімацію для кожного файлу, сповільнюючи весь процес практично непридатним.

Сучасні копіювальні матеріали для Windows не набагато кращі:

• Для обчислення обсягу даних для передачі, здається, спочатку робиться пошук (саме це я думаю, це і робиться), тому потрібно багато років, якщо ви виберете багато каталогів, поки він ефективно не почне виконувати цю роботу.
• Деякий вбудований тайм-аут закликає копіювати великі файли (> близько 60 Гб у моїй системі). Біль полягає в тому, що це говорить вам про те, що після копіювання вже більше 30 Гб по мережі, і це втрачається пропускною здатністю і часом, тому що вам доведеться перезапустити з нуля!
• Копіювання файлів з одного комп'ютера на інший чомусь повільно повільно. (Я маю на увазі порівняно з доступною пропускною здатністю мережі, використовуючи інші інструменти, це швидше, тому це не обчислювальне обмеження.)

Про це одного разу написав Реймонд Чен. В основному, діалог просто вгадується :).

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

"Оскільки діалог про копіювання просто здогадується. Він не може передбачити майбутнє, але він змушений спробувати. І на самому початку копії, коли історія мало пройти, прогнозування може бути дуже поганою.

Ось аналогія: припустимо, хтось скаже вам: "Я буду рахувати 100, і вам потрібно давати постійні оцінки того, коли я буду робити". Вони починаються, "один, два, три ...". Ви помічаєте, що вони йдуть приблизно на одне число в секунду, тому ви оцінюєте 100 секунд. А-о-о, тепер вони сповільнюються. "Чотири ... ... ... п'ять ... ... ..." Тепер ви повинні змінити свою оцінку, можливо, на 200 секунд. Тепер вони прискорюються: "шість-сім-вісім-дев'ять" Вам доведеться ще раз оновити свою оцінку.

Тепер хтось, хто слухає лише ваші оцінки, а не людина, яка рахує, вважає, що ви з вашого рокера. Ваша оцінка пішла від 100 секунд до 200 секунд до 50 секунд; у чому проблема? Чому ви не можете дати хорошу оцінку?

Копіювання файлів - це те саме. Оболонка знає, скільки файлів і скільки байтів буде скопійовано, але вона не знає, наскільки швидкий буде жорсткий диск чи мережа чи Інтернет, тому він просто повинен здогадатися. Якщо пропускна здатність копії змінюється, оцінку потрібно змінити, щоб врахувати нову швидкість передачі ".

Я буду рахувати десять, 1....2....3....4скільки крапок потрібно взяти, щоб дістатися до 10?

5.6.7А зараз? Чи берете ви до уваги всі минулі точки між числами та середнє значення, чи берете лише останні 4 інтервали та використовуєте це середнє значення, чи дивитесь ви лише на останній інтервал?

У вас така ж проблема з передачею файлів. Швидкість, яку передає файл, не є постійною, вона прискорюється і сповільнюється на основі безлічі факторів. Причиною, що число скаче настільки багато, Microsoft нахилилася до сторони спектра "тільки підрахунок останнього інтервалу".

З цією стороною спектру немає нічого поганого, він дає точніші "секунди за секунду" (одна секунда в режимі реального часу змушує лічильник знижуватися на одну секунду), але це призводить до того, що загальний показник ETA таймера може багато стрибати .

Хорошим прикладом протилежної сторони є 7-Zip при його стисненні. Якщо швидкість стиснення падає під час його обробки, ви можете бачити, що ETA не стрибає різко, як ETA передачі файлів, але це може зайняти 2–3 реальні секунди, перш ніж таймер відключиться на одну секунду (або він навіть може почати відлік часу) ), поки він не стабілізується на новій швидкості.

Там насправді майже канонічний відповідь на Microsoft Раймонд Чен про це від WAAAAAY тому, і є кілька частин , щоб головоломки.

Тому що діалогове вікно копіювання - лише здогадки. Він не може передбачити майбутнє, але він змушений намагатися. І на самому початку копії, коли історія мало пройти, передбачення може бути дуже поганим.

По-перше, що Windows здогадується. Він знає, скільки файлів і наскільки вони великі, але швидкість передачі на файл сильно відрізняється. Це залежить від таких речей, як розмір або навіть розташування на диску, в деяких випадках. З плином часу він коригує свої здогадки, виходячи з поточних та минулих умов, і, як такий, у вас є неточні розрахункові швидкості передачі в реальних умовах.

Ось пояснення по Raymond Chen , головний інженер - програміст Проектування в Microsoft:

Чому діалог копіювання дає такі жахливі оцінки?

Тому що діалогове вікно копіювання - лише здогадки. Він не може передбачити майбутнє, але він змушений намагатися. І на самому початку копії, коли історія мало пройти, передбачення може бути дуже поганим.

Ось аналогія: припустимо, хтось скаже вам: "Я буду рахувати 100, і вам потрібно давати постійні оцінки того, коли я буду робити". Вони починаються, "один, два, три ...". Ви помічаєте, що вони йдуть приблизно на одне число в секунду, тому ви оцінюєте 100 секунд. А-о-о, тепер вони сповільнюються. "Чотири ... ... ... п'ять ... ... ..." Тепер ви повинні змінити свою оцінку, можливо, на 200 секунд. Тепер вони прискорюються: "шість-сім-вісім-дев'ять" Вам доведеться ще раз оновити свою оцінку.

У цитованому вище дописі на блозі тривало обговорення цього питання з цікавими коментарями.

Реймонд Чен - легендарна людина, «Чак Норріс Майкрософт», я не думаю, що ви отримаєте більш авторитетну відповідь. Я впевнений, що він хоча б бачив код, про який йде мова.

Очевидна причина полягає в тому, що швидкість передачі змінюється з часом, а також середня величина, а також прогнозування. Щоб пояснити це другові, який не працює в техніці, я використав аналогію, що передбачає подорожі по повітрю. Ви збираєтесь летіти над Атлантикою. Коли ви приїжджаєте з таксі в аеропорт, що відправляється, ваш ETA складає близько двох місяців. Коли ви висадитесь в аеропорт, що прибуває, виходячи з вашої середньої швидкості до цих пір, ви доїдете до будинку свого друга за 5 секунд.

Але вам потрібно оцінити, наскільки насправді може змінюватись швидкість, навіть при тому, що здається передбачуваним сценарієм, як копіювання файлів на один і той же диск або між двома локальними дисками. Однією з нових функцій, які мені подобаються в Windows 8, є можливість графікувати швидкість у часі, якщо натиснути «більше деталей». Якщо у вас немає доступу до машини Windows 8, шукайте зображення для діалогового вікна копіювання Windows 8 для багатьох прикладів. Багато з них досить плоскі, але багато з них також тривожно бухають, до того, що вам цікаво, чи жорсткий диск насправді здоровий, коли він опускається до нуля.

Деякі з цих ударів, ймовірно, пов'язані з різницею розміру файлу - менші поля дають більше доступу, що сповільнює роботу, особливо на механічному жорсткому диску, який потрібно шукати, переміщуючи голову зчитування, але деякі можуть бути просто дешевим накопичувачем, який кінці з найменшим дотиком, щоб запобігти пошкодженню блюд.

Є кращі та гірші алгоритми прогнозування ETA, але для точного прогнозування комп'ютер повинен був би бути всезнаючим. Ризик спробувати зробити алгоритм «розумним» полягає в тому, що він може створювати нові, непередбачені випадки, коли це ще більше химерно неправильно.

Єдиний спосіб дізнатися, скільки часу знадобиться для стиснення набору файлів - це стиснення їх. Іноді найкраща здогадка Windows близька, іноді це дико неправильно. Те саме стосується копіювання великої кількості файлів, як я впевнений, ви помітили.

Це не стільки помилка, скільки марний показ рідко точної інформації. Найкращий спосіб виправити це - закрити очі. Ігноруйте це. ;-)

Можливо, там є програма, яка може копіювати / стискати файли та видавати сигнал тривоги, коли вона закінчується. Це було б справді корисно. Ми могли б трохи подрімати, поки будемо чекати, поки Windows закінчить прибирання будинку.

Я думаю, що причина була добре пояснена в одному з коментарів до повідомлення в блозі, пов’язаному з відповіддю Роалда:

У ньому є жахливий алгоритм оцінки. Виправдань немає. Якщо вам доведеться скопіювати 1000 файлів 1 КБ та 10 файлів 1 МБ, він вважає, що це буде так само зайнято файлом 1 Мб, як і файлами 1 КБ.

Причина, по якій він дає такі жахливі оцінки, полягає в тому, що це недостатньо зроблено. Очевидно, що він ніколи не може бути на 100% точним, але може бути набагато, набагато кращим.

З метою прискорення процесу копіювання (не витрачати занадто багато часу на обчислення прогнозу часу замість виконання операцій, пов’язаних із копією), утиліта копіювання Windows, вбудована в Провідник, підтримує обмежений обсяг інформації про те, як швидко завершилися попередні операції запису. Кожен раз, коли йому потрібно обчислити час, що залишився, він просто визначає середню кількість операцій запису часу, а потім помножує на кількість операцій запису, що залишилися.

Проблема полягає в тому, що кількість часу, необхідне для виконання операції запису, не є постійною - вона насправді може суттєво відрізнятися. Тож це, у свою чергу, призводить до значних змін у оцінці часу.

Слід враховувати 3 фактори:

1. Загальний розмір переказу.
2. Кількість файлів для передачі.
3. "Зайнятість" засобів масової інформації, а можливо, і зв'язок.

Числа 1 і 3, мабуть, мають найбільш очевидний вплив на обчислення часу передачі, але дуже багато людей не враховують число 2. Це може мати величезний вплив на те, як триватиме передача, і їх важко оцінити.

В основному, щоразу, коли файл записується у файлову систему, потрібно написати трохи метаданих про файл, наприклад. право власності, дозволи, створення / модифікація / час доступу тощо. Залежно від конкретної файлової системи, ця інформація може бути записана на частину диска дуже "далеко", звідки вони записуються. Ця накладна файлова система - це те, що може зробити заздалегідь просту передачу багато часу та / або зробити так, щоб оцінка часу динамічно коливалася.

наприклад: Передача одного великого файлу ви помітите, що оцінка є стійкою і досить точною, але перенесення сотень файлів різного розміру, але однакового загального розміру, може зайняти більше часу і призвести до того, що оцінка часу пригодиться.

У поточних алгоритмах оцінки є три недоліки.

Всупереч поширеній думці, їх не так вже й складно, щоб перекинути руки.

Причина, по якій більшість людей пише блоги, і люди, які не знають про цю можливість, є найкращою, як я можу сказати, через сферу навчання та широту навчання в школі. Скромний, але також дуже комфортний засіб має бути можливим для [випускника, який отримав більш недавню підготовку, ніж письменники блогів] [компанії, що використовує багатомільярдні долари] Microsoft.

Я спробую приблизно пояснити, чому.

Точки відмови наступні. Ядро:

1. не може достовірно передбачити майбутнє завантаження вводу-виводу через обставини, що не входять в область ядра

• з цим нічого не слід робити, оскільки це дуже необмежена проблема P = NP.

2. не відслідковує евристику IO на будь-якому корисному рівні деталізації. Використання - набагато ширше поняття, ніж швидкість читання / запису диска / мережі .

• для цього потрібно зробити дуже мало, трохи більше, ніж відслідковувати основні відомості про використання IO

  • з диска
    • розмір середньої швидкості читання 1a
    • середня швидкість запису файлів, розмірність 2a
  • на основі кванту * відповідно до
    • розмір розміру файлу b
    • розташування файлу на розмірі диска c
  • * квантовано у [ймовірно] не більше 3 категорій. Зменшення розмірності допоможе нам визначитись напевно, але 3 повинні бути достатніми для (можливо, досить ефективних) механізмів прогнозування, що не є кращими:
    • розмір файлу
      • світла
      • середній
      • важкий
    • місцезнаходження [інформує про затримку пошуку]
      • початок
      • середній
      • ви отримаєте бал
    • розмір та розташування файлів надмірні / перекриваються зі швидкістю читання / запису, це навмисно
  • нам потрібно знати, наскільки "зайнятим" був диск, щоб ми могли припустити, що він буде залишатися таким зайнятим розміром d
    • обчислюється з кількості прочитаних файлів, пов'язаних з їх відповідною вагою
    • використовується для оцінки часу на початку копіювання ... діалогове вікно, засноване на майбутньому очікуваному навантаженні, якщо все інше, окрім цього діалогового вікна копіювання, продовжується так, як зараз
  • метод запису для цілей ... тут патентоспроможності

3. Якби їх відстежували , не мали б користі для евристики

• тут мало зроблено, де ми виконуємо більшу частину роботи
• саме тут ми поміщаємо дані з №2 для використання
  • грубий статистичний аналіз ваг файлів і розташування, щоб визначити, скільки скакань ми будемо робити. Вага + розташування дає нам передбачення
  • комбінувати з поточними вагами та навантаженнями на диски
  • щоб оцінити те , що ми вважаємо , що середня швидкість читання / запису числа файлів розмір е буде
  • яку ми порівнюємо, щоб налагодити нашу модель
  • що дозволить нам досить точно оцінити смугу прогресу та час до його завершення
• метод аналізу для цілей прогнозування ... тут патентоспроможності

Суть у цьому в нашій моделі лише 2a = F * (bxc) + d комплекс

У випадках, коли a, b і c мають 3 стану: кожен менеджер файлів визирає до файлів (або лише метаданих) перед копіюванням, а F * (bxc) + d не є дорогим обчисленням; якщо ви хочете чогось більш точного, використовуйте таблицю пошуку з більшою кількістю станів - навряд чи є якийсь розрахунок.

зауважте: розміри тут для блюда, вони будуть різними, якщо SSD - початок / середина / кінець не матиме значення

Ключовою різницею між тим, що я описав, та попередніми реалізаціями, які ми бачили до цього часу, буде коротке спостереження за розміром файлів та дистрибуцією / ентропією файлів на диску та використанням його для [більш] точного врахування часового елемента використання диска.

(патент залишається як вправа для читача ...)

Коли ви намагаєтеся передбачити, як довго щось триватиме, існує багато "невідомих" змінних. Наприклад, хоча програма знає, що є 3500 файлів і що файли розміром 3,5 ГБ (3500 МБ), чи означає це, що кожен файл становить 1 Мб? Не обов'язково. Тут може бути багато 4 КБ файлів, а також 100 файлів по 100 МБ та деякі інші між ними. Крім того, ви повинні врахувати, звідки беруться файли та куди вони переходять (наприклад, медіа.) Що є найбільшим вузьким місцем? Як ви намагаєтеся скопіювати файли з жорсткого диска через тунель VPN ? Ви даєте найкращий сценарій випадку, а потім налаштовуєте свої лічильники в режимі реального часу. Ось чому ви бачите, що ці вимірювачі прогресу змінюються на льоту.

Математично правильна модель полягає в тому, щоб насправді провести наївне усереднення та екстраполяцію:

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

Причина полягає в тому, що Законом про великі числа локальні коливання скасуються із усередненою швидкістю передачі , і це дасть найбільш стабільний результат.

Microsoft, схоже, робить, це обчислити швидкість передачі за останній часовий період. Це означає, що кожне локальне коливання суттєво змінює результат.

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

Як сказав Роальд ван Доорн, це в основному лише здогадки. Звичайно, це не означає, що він не міг бути кращим здогадком. Є багато евристик, які можна використати для обчислення цього.

1. Найкращий спосіб, найдорожчий спосіб, - це зберегти історію попередніх "копій", а потім використовувати алгоритми штучного інтелекту для обчислення здогадів
2. Можна було б побудувати формулу, засновану на дослідженні того, скільки часу це повинно зайняти. Вони могли враховувати такі речі, як: файлова система, кількість файлів, розмір файлів, час пошуку диска, швидкість масового читання / запису диска, розташування файлів на диску (фрагментація), використання поточного диска.
3. Суміш двох. Тобто зробіть кілька орієнтирів, щоб з’ясувати, скільки часу займають певні операції, а потім використовувати їх як історію для простих формул.

Очевидно, що нічого з цього не реалізується легко .. і я згадав лише копії файлів. Аналогічну роботу потрібно провести для всіляких передач.
Питання, яке ви повинні задати собі: чи не хотіли б ви, щоб мікрософт витрачав час, даючи вам кращу оцінку, чи, швидше, вони змусять швидше передавати ваші файли.

Однак якщо щось стиснути за допомогою 7-блискавки, ви помітите, що це набагато краще, ніж здогадки, ніж Windows. Я сумніваюся, що це робить щось таке складне, просто трохи кращий здогад.

Коротше кажучи, розрахунок базується на поточній швидкості передачі .

Наприклад: Якщо швидкість передачі даних пропадає через те, що Windows має копіювати величезну кількість крихітних файлів, очікуваний час збільшується лінійно і навпаки для великих файлів.

Передбачити, якою буде швидкість передачі протягом усього процесу передачі, майже неможливо , оскільки це залежить від багатьох факторів, таких як розмір файлів, використання процесора, помилки передачі тощо.

У публікації блогу MSDN є кілька цікавих відповідей Покращення наших основ управління файлами: скопіюйте, перемістіть, перейменуйте та видаліть з цього приводу. Щодо того, чому це важко:

Оцінити час, який залишився для завершення копії, майже неможливо зробити з будь-якою точністю, оскільки є багато непередбачуваних та неконтрольованих змінних - наприклад, яка пропускна здатність мережі буде доступна для тривалості завдання копіювання? Чи розпочнеться антивірусне програмне забезпечення та почне сканувати файли? Чи потрібна інша програма для доступу до жорсткого диска? Чи розпочне користувач інше завдання копіювання?

І як вони вдосконалюються,

Замість того, щоб інвестувати багато часу, придумуючи низьку оцінку довіри, яка була б лише дещо покращена в порівнянні з поточною, ми зосередилися на поданні корисної та переконливої ​​інформації, в якій ми впевнені. Це робить найнадійнішою інформацією, яку ми маємо у вас, щоб ви могли приймати більш обґрунтовані рішення.

Це означає, що якщо ви дійсно хочете покращити дану оцінку і зберегти смугу прогресу такою, якою вона є, ви можете зробити щось запропоноване в коментарі Slashdot :

Підтримуйте таблицю очікуваних швидкостей для кожного пристрою зберігання файлової системи. Запишіть, скільки часу потрібно для зчитування інформації файлової системи. Коли пристрій встановлено, якщо це підходить для типу пристрою, прагніть до середини та кінця, також вимірюйте швидкості. Отримайте приблизні криві швидкості читання та запису в різних місцях та використовуйте їх для подальших оцінок. Для майбутніх операцій читання та запису відзначте, де вони знаходяться та як швидко вони йдуть, і відповідно регулюйте криві.

Коли операція починається, подивіться криві введення та виведення для відповідних пристроїв. Знайдіть очікувану швидкість для цільового місця розташування. Яка б швидкість була нижчою, слід використовувати для оцінки.

Хотілося лише додати, що загальна кількість файлів легко є найбільш трудомістким фактором операцій копіювання файлів на ПК. Я завжди можу запам'ятати, як молодий студент, свідомо спричиняючи збій ПК у моєму класі обчислень, починаючи з 1 файлу без вмісту та копіюючи його, потім вибираючи 2 файли та копіюючи знову тощо. Після того, як він пройшов близько 1024 файлів, у нього зайняло величезна кількість часу, щоб зробити що-небудь, навіть коли він копіював ніяку інформацію, крім економії для заголовка файлу. Спробуйте самостійно навіть на новій ОС, експоненціальній копії файлу, і ви побачите, що відбувається. Їжа для роздумів.

Я щойно скопіював 200 ГБ з USB HDD на основний диск. Було близько 130000 файлів

Після перших 4-5 хвилин я помітив, що:

• Для найменших файлів швидкість становила близько 100 файлів в секунду зі швидкістю близько 600 КБ / с
• А для великих файлів це було як 70 Мб / с

На початку Windows змінив оцінку від 1 години до 5+ годин, потім назад до 1 години тощо. Зрештою, як у 95%, вона все ще змінювала оцінку з 10 хвилин до 10+ годин. Тож замість того, щоб стати більш точним, воно йшло все менш і менш точно.

Прості математичні шоу:

130 000 файлів зі 100 файлами в секунду = 22 хвилини

200 000 МБ при 70 Мб в секунду = 47 хвилин

22 хвилини - розкутавшись у часі пошуку, копіюючи файли розміром кілька кілобайт. 47 хвилин - час, який знадобиться для передачі фактичних даних, якщо немає часу на пошук.

Сума 22 хв + 47 хв - це абсолютний максимальний час, який це може зайняти.

Тож очевидно, що оцінка повинна бути десь від 47 до 69 хвилин.

Що показує діалогове вікно приблизно на 90%: "Я копіюю невеликі файли з частотою 1 Мб / с, на 20 ГБ більше даних. На завершення знадобиться 5:30 годин.

Кілька секунд пізніше: "Я копіюю великий файл сюди, зі швидкістю 70 Мб / с, це займе 4 хвилини.

Що людина насправді бачить із того самого діалогу: 120 000 файлів та 180 ГБ вже копіюються за 40 хвилин. Решта 10000 файлів і 20 Гб повинні займати близько 5 хвилин

Діалогове вікно дає достатньо інформації, щоб зробити обчислення, які з кожним секундою стають все точнішими. Він знає швидкість, з якою копіюються невеликі файли. Він знає, з якою швидкістю копіюються великі файли. Він також знає, скільки файлів і скільки байтів залишилось.

Настільки просто зробити таке точне припущення лише встановивши верхню і нижню межу.

Діалогове вікно показує трохи правильніші дані лише у випадку, коли великі файли знаходяться перед малими файлами. У такому випадку він починається через 40 хвилин, а через 30 хвилин він починає копіювати невеликі файли і каже "ну, мені потрібно ще 20 хвилин".

Але коли маленькі файли на початку та великі файли - у кінці. Діалогове вікно насправді не переймається тим, які "файли в секунду" передають невеликі файли. Це робить його обчислення так, як кількість малих файлів - це нескінченність, і таке, як вони, назавжди буде малим.