Чому швидкість копіювання мого мережевого файлу утворює хвилю?

З оновленням до Windows 10 я отримав цей гарний графік під час копіювання файлів.

Коли я копіюю один великий файл, швидкість завжди приймає цю досить послідовну форму хвилі. Що це викликає?

З'єднання є

My PC <- cable -> gigabit switch <- cable -> Netgear ReadyNAS

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

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

networking nas

— Грісі
джерело

Ще кілька деталей про конфігурацію диска ReadyNAS допоможуть. Ви використовуєте RAID 5 на трьох накопичувачах? Яка швидкість запису на кожному диску? Що таке буфер на кожному диску та чи є кеш, який використовує ReadyNAS? Ви спробували інші інструменти, такі як TeraCopy, щоб побачити, чи різняться ваші швидкості передачі? Якщо ні, то може бути вузьке місце із записом кеш-диска, особливо якщо частота запису не є хорошою (наприклад, Seagate Barracuda).

— Нд

Ви закривали всі інші процеси, які могли використовувати NAS через інтервали?

— Ар’ян

Відповіді:

Коротка відповідь: Запишіть кеш

TL; DR: По-перше, набагато менше накладних витрат при копіюванні одного великого файлу, порівняно з багатьма меншими. Це означає, що ПК та NAS не витрачають багато часу на пошук файлів, оновлення файлової таблиці та метаданих файлової системи. Це також означає набагато більшу пропускну спроможність, що, ймовірно, виявить деякі вузькі місця пропускної здатності в налаштуваннях.

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

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

Врешті-решт буфер запуститься повноцінно і його потрібно записати на диск. Тим часом NAS не може отримувати дані так швидко, як раніше, оскільки у нього немає де їх зберігати (буфер заповнений, а диски повільніше). Тут ви отримуєте долини графіка.

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

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

— абстраск
джерело

Хіба це не призведе до горизонтальної лінії з раптовими шипами (приблизно до нуля), коли буфер буде заповнений?

— Ар’ян

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

— абстракс

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

Це може нормалізувати TCP "гребінці". TCP працює якнайшвидше, поки не зазнає втрати пакету. Потім трохи відступає і знову підскакує. Таким чином, він продовжує "битися головою об стелю". Ось так воно максимально збільшує пропускну здатність, не збільшуючи перевантаженість. Я зазвичай дивлюся на гребінці TCP в графіку TCPTrace, який трохи відрізняється від цього графіка. Я б очікував, що це буде виглядати трохи більше пилоподібного типу в такому вигляді графіка, але в цьому графіку може бути деяке згладжування. А тепер, коли я замислююся над цим, гребінці TCP опиняться у набагато меншому часовому масштабі, ніж це показано на графіку.

Можливо також, що ваш протокол віддаленої файлової системи (SMB) одночасно зчитує фрагмент файлу, і провали - це місце, коли закінчено прочитання одного фрагмента, а наступний - запит.

— Spiff
джерело

Вибачте за відсутність деталей, я не був впевнений, що люди повинні знати. Я використовую smb, і цей графік охоплює близько хвилини

— Грицей

@Gricey: Не коментуйте це: виправте питання !!

— Гонки легкості з Монікою

-1 для непотрібних

— нітропікінг

@LightnessRacesinOrbit виправлено

— Gricey

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

— Spiff

Я думаю, що Microsoft представила цю функцію на панелі прогресу в Windows 8.

Зліва направо відображається хід у відсотках , а рух вгору вниз показує швидкість передачі в Мб / с .

Швидкість передачі визначається швидкістю носія інформації (BUS або Network), кількістю та розміром файлів, файловою системою та наявністю ресурсів тощо.

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

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

Для подальшого роз'яснення тут читаються далі

— каламбур
джерело

Це насправді не відповідає на питання.

— Гонки легкості з Монікою