Чому я отримую 950 Мбіт / с, але лише 360 Мбіт / с на гігабітному Ethernet?

У мене два настільних комп’ютери безпосередньо спілкуються один з одним. Вони обидва мають мережеві адаптери, що підтримують Gigabit Ethernet. Це 1 Гбіт / с або 1000 Мбіт / с. У мене вони пов'язані з абсолютно новим прямим кабелем Cat6 UTP довжиною 10 метрів, і я наближаюся до цього теоретичного максимуму. Менеджер завдань Windows (вкладка "Мережа") показує 844 - 946 Мбіт / с в одному напрямку. Але в іншому напрямку він показує лише близько 326 - 365 Мбіт / с.

Local: 192.168.100.152
Remote: 192.168.100.151

Локальний комп'ютер працює під керуванням Windows 8.1 Pro, і я його віддалено підключив до іншого комп'ютера, на якому працює Windows Vista Ultimate.

Результати Iperf

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

192.168.100.152 -> 192.168.100.151          106 MB/s
192.168.100.152 -> 192.168.100.151          107 MB/s
192.168.100.152 -> 192.168.100.151          108 MB/s
192.168.100.152 -> 192.168.100.151          107 MB/s
192.168.100.152 -> 192.168.100.151          107 MB/s
192.168.100.152 -> 192.168.100.151          104 MB/s
192.168.100.152 -> 192.168.100.151          101 MB/s
192.168.100.152 -> 192.168.100.151          108 MB/s
192.168.100.152 -> 192.168.100.151          108 MB/s
192.168.100.152 -> 192.168.100.151          108 MB/s
----------------------------------------------------
Min: 101 MB/s    Max: 108 MB/s    Avg: 106.4 MB/s (851.2 Mbps)

192.168.100.152 <- 192.168.100.151          41.1 MB/s
192.168.100.152 <- 192.168.100.151          41.1 MB/s
192.168.100.152 <- 192.168.100.151          41.1 MB/s
192.168.100.152 <- 192.168.100.151          41.0 MB/s
192.168.100.152 <- 192.168.100.151          41.0 MB/s
192.168.100.152 <- 192.168.100.151          41.1 MB/s
192.168.100.152 <- 192.168.100.151          41.0 MB/s
192.168.100.152 <- 192.168.100.151          41.1 MB/s
192.168.100.152 <- 192.168.100.151          41.1 MB/s
192.168.100.152 <- 192.168.100.151          41.1 MB/s
-----------------------------------------------------
Min: 41.0 MB/s    Max: 41.1 MB/s    Avg: 41.07 MB/s (328.56 Mbps)

Моє запитання: чому це так повільніше в іншому напрямку?

Менеджер завдань Windows

Це мережева діаграма, як видно під час виконання тестів в Iperf.

Зверніть увагу на схему на наступних двох скріншотах!

Ви помітили, як це змінилося з "1 Гбіт / с" на "500 Мбіт / с" у верхньому правому куті, коли я перейшов від надсилання даних до отримання даних. Чому це зробили? Чи якимось чином сприймає інший мережевий порт як половину 1 Гбіт / с, коли йдеш в одну сторону, але все ж повний, коли йдеш навпаки?

Тест на передачу файлів

Я зробив ще тестування з файлом даних, щоб отримати більш реалістичний диск для читання дисків. Я створив для цього файл 1 Гб. Я використовував лише засоби спільного використання файлів Windows за замовчуванням. З локального комп’ютера я підключився до C $ share на віддаленому комп’ютері і перетягнув і перекинув файл назад і назад (пропускаючи мотузку) між ними, щоразу змінюючи ім’я файлу. Я приурочила все якнайкраще, і це те, що я отримала.

192.168.100.152 -> 192.168.0.151    1073741824 Byte    25 s    40,96 MB/s
192.168.100.152 -> 192.168.0.151    1073741824 Byte    20 s    51.2 MB/s
192.168.100.152 -> 192.168.0.151    1073741824 Byte    16 s    64 MB/s
192.168.100.152 -> 192.168.0.151    1073741824 Byte    16 s    64 MB/s
192.168.100.152 <- 192.168.0.151    1073741824 Byte    11 s    93.091 MB/s
192.168.100.152 <- 192.168.0.151    1073741824 Byte    34 s    30.118 MB/s
192.168.100.152 <- 192.168.0.151    1073741824 Byte    11 s    93.091 MB/s
192.168.100.152 <- 192.168.0.151    1073741824 Byte    11 s    93.091 MB/s

Пропускна здатність, вказана на схемі копіювання файлів Windows, розповідає про іншу історію. Тут я завантажую два файли, один за одним, до двох різних місць на одному диску. У першій копії було вказано, що 107 Мб / с підтримують до 41%, а в другій - 98,9 Мб / с, до 87%.

Отже, це відповідає результатам, які я отримав за допомогою інструменту Iperf. Тепер ось, як це виглядає, коли я завантажую на віддалений комп'ютер.

Він підтримує від 103 Мб / с до 73%, а потім знижується до смердючих 27,3 Мб / с при 82%, а потім піднімається на висоту до 49,1 Мб / с при 93%.

Ось ще дві смішні на вигляд діаграми «американські гірки».

Оновлення 1 - Швидкість зв'язку

Я спробував відключити адаптер Wifi на віддаленому комп’ютері. (Адаптер Wi-Fi вже був відключений на локальному комп’ютері.) Я думаю, що саме це мав на увазі Timtech під цим коментарем. У мене була така ж думка - що ввімкнення одночасно дротових і бездротових адаптерів обмежило пропускну здатність провідного адаптера рівнем адаптера Wifi (адаптуючись до найповільнішого адаптера для сумісності). Оскільки адаптер Wifi (в даному випадку DWA-160 Wireless N) зазвичай визначається як "52 Мбіт / с" - "104 Мбіт / с" за допомогою комп'ютера Vista.

На наступному скріншоті віддалений комп'ютер налаштовується як сервер, а локальний комп'ютер - як клієнт (192.168.100.152 <- 192.168.100.151).

Але відключення адаптера Wifi на віддаленому комп’ютері не допомогло моїй низькій пропускній здатності на моєму дротовому з'єднанні.

Не лише це! У Windows Task Manager на віддаленому комп'ютері швидкість зв'язку для провідного адаптера (LAN 1) відображається як "1 Гбіт / с". Якщо ви посилаєтесь на знімки екрана, ви побачите, що він виявляється як посилання "500 Гбіт / с" на локальному комп'ютері. Отож, для того ж дротового з’єднання Windows Vista каже, що це посилання на 1 Гбіт / с, тоді як Windows 8.1 Pro каже, що це посилання на 500 Гбіт / с ... яке з них є правильним?

Ось як це виглядає на віддаленому комп'ютері, коли я його налаштував як клієнт, а локальний комп'ютер як сервер (192.168.100.152 -> 192.168.100.151).

Як ви бачите тут, використовується близько 95% посилання 1 Гбіт / с. Це означає 950 Мбіт / с. Це саме те, що я отримав у тесті вище. Але йти навпаки - це зовсім інша історія.

Оновлення 2 - Дуплексинг та MDI-X

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

Я спробував змінити на "1,0 Gbps Full duplex" на обох комп'ютерах. Потім я робив ті ж типи тестів, що і раніше, використовуючи Iperf. З локальним комп'ютером як сервером та віддаленим комп'ютером як клієнтом я отримую максимум 950 Мбіт / с. З локальним комп'ютером як клієнтом та віддаленим комп'ютером як сервером я отримую близько 360 Мбіт / с.

Ось подивіться ці скріншоти.

Тут ви бачите схему, коли я завантажую та завантажую між двома комп'ютерами. Вищий графік (95 - 98% використання) є локальним та віддаленим (вище за течією 192.168.100.152 -> 192.168.100.151). Нижній графік (~ 33% використання) віддалений до локального (нижче за течією 192.168.100.152 <- 192.168.100.151).

Щоб спробувати виключити будь-які проблеми Auto MDI-X, у мене був один з таких адаптерів кросовера, приєднаний до одного кінця кабелю (локальний комп'ютер).

Це, безумовно, зробить кабель перехресним кабелем. Чорт, у мене навіть був тестований мережевий тестер! Він справді перекреслений (шпильки 1/3, 2/6)!

Тож тепер у мене справжній перехресний кабельний зв’язок між двома комп'ютерами, і я встановив "1,0 Гбіт / с повний дуплекс". І все-таки у мене така ж проблема. Ще ідеї? Крім оновлення комп'ютера Vista (або перевстановлення комп'ютера 8.1)?

Оновлення 3 - Обмеження програмного чи апаратного забезпечення?

Я найкраще здогадуюсь, що у мене є дві операційні системи, несумісні одна з одною. Вони обидві системи Windows, але не всі системи Windows рівні. Мені доведеться спробувати використовувати Vista на обох або 8.1 Pro на обох і подивитися, яку пропускну здатність я отримую. Це означає купувати оновлення. Блін ти Microsoft.

Обидва комп'ютери до речі побудовані на замовлення. Ось кілька специфікацій.

Local
-----
Gigabyte GA-EP45-UD3R
Intel Core 2 Quad Q9650
Intel P45
Corsair XMS2 DHX TwinX DDR2 PC6400/800MHz 4 GB
Realtek 8111C chips (10/100/1000 Mbit)
WD Caviar Black WD1002FAEX
Windows 8.1 Pro 64-bit

Remote
------
Gigabyte GA-X38-DQ6
Intel Core 2 Duo E4500
Intel X38
Corsair XMS2 DHX TwinX DDR2 PC6400/800MHz 4 GB
Dual Realtek 8111B chip (10/100/1000 Mbit)
WD Caviar Black WD1002FAEX
Windows Vista Ultimate 64-bit

Тоні припустив, що машина Vista може використовувати поганий чіп Realtek. Тому я викопав ці характеристики. Тепер я бачу, що машина Vista використовує B-версію 8111, а локальна машина використовує C-версію тієї ж мікросхеми. Це щось означає? Обидва вони чітко визначені виробником на 1000 Мбіт (див. Вище). Чи може бути, що 8111B настільки низькопродуктивний (360 Мбіт / с)?

Ці накопичувачі досягають швидкості розриву 107 Мб / с. Саме стільки я бачив під час тесту на локальному комп’ютері. Але навіть стійке послідовне чи випадкове читання / запис, можливо, 55 Мб / с НЕ перетворює на 360 Мбіт / с. Це повинно дати мені десь 440 Мбіт / с, а не 360 Мбіт / с, які я отримую. Тож я не підозрюю, що це вузьке місце, тим більше, що вони обидва використовують однакову модель приводу. Окрім того, операція копіювання файлів - одне, але Iperf взагалі не використовує диски, для тестів використовує лише оперативну пам’ять.

Оновлення 4 - Вивантаження контрольної суми TCP

Як запропонував Тонні, я спробував вимкнути розвантаження контрольної суми TCP (для IPv4 та IPv6).

Я також переключив "Швидкість і дуплекс" назад до автоматичного для обох комп'ютерів. Але це не допомогло. У мене все ще низька пропускна здатність в одному напрямку, а висока в іншу сторону.

Оновлення 5 - Нова версія драйвера

Я спробував оновити драйверну версію як локальної, так і віддаленої до останньої версії, завантаженої з веб-сайту Gigabyte та веб-сайту Realtek.

Update path...

On local (RTL8111C):
8.1.510.2013 (2013-05-10, Microsoft)
8.20.815.2013 (2013-08-15, Realtek)

On remote (RTL8111B):
6.241.623.2010 (2010-06-23, Realtek)
6.250.908.2011 (2011-09-08, Realtek)
6.252.1109.2012 (2012-11-09, Realtek)

Я все одно отримав таку ж вакуумну пропускну здатність в одному напрямку.

Оновлення 6 - Використання процесора

Я перевірив використання процесора. Це не повинно бути проблемою. Ось мої висновки.

On local...

Download: 4 - 10 %
Upload:   4 - 10 %
Idle:     0 -  4 %

On remote...

Download: 24 - 38 %
Upload:   10 - 25 %
Idle:      1 -  6 %

Місцевий (завантаження, завантаження, очікування) ...

Віддалене (завантаження, завантаження, очікування) ...

Пульт використовує набагато більше потужності процесора, але це також той, який має повільніший Core 2 Duo. Але вона ніколи не перевищувала 38% балів під час моїх тестів. Тут особливо цікаво те, що він використовує набагато більше енергії процесора при завантаженні (локальний -> віддалений), ніж при завантаженні (локальний <- віддалений).

Так, при пропускній здатності 950 Мбіт / с він використовує 38%, а при 360 Мбіт / с - 25%. Також використання ядра не збалансоване, воно використовує одне ядро ​​більше, ніж інше. Я не впевнений, який висновок зробити з цього. Місцевий комп'ютер не відображає використання ядра, тому я не можу порівняти його. Але використання процесора навіть на локальному комп'ютері (10% при завантаженні / завантаженні).

Оновлення 7 - Новий мережевий адаптер Intel Gigabit

Зараз я встановив абсолютно новий мережевий адаптер PCI-Express Gigabit від Intel в якості заміни вбудованого Realtek RTL8111B на віддалений комп'ютер, який нібито занадто повільний при завантаженні. Номер продукту адаптера Intel - EXPI9301CT. Цей адаптер повинен бути дуже хорошим згідно з прочитаними відгуками. Я просто хочу виключити це як можливе вузьке місце.

Я зробив кілька тестувань зараз з Iperf для Windows, і ось результати.

Місцеві (скачати, завантажувати) ...

Віддалене (завантаження, завантаження) ...

У середньому цей адаптер насправді трохи повільніше, ніж адаптер Realtek. Я думаю, що вона має менші накладні витрати, ніж Realtek, і внаслідок цього стабільніша безперервна пропускна здатність. Але я все одно отримую лише близько 360 Мбіт / с в одному напрямку і 950 Мбіт / с в іншому, навіть із цим адаптером Intel.

local: 192.168.100.152 (win 8, realtek 8111c)
remote: 192.168.100.154 (vista, intel desktop ct)

192.168.100.152 -> 192.168.100.154    113 MB/s
192.168.100.152 -> 192.168.100.154    104 MB/s
192.168.100.152 -> 192.168.100.154    103 MB/s
192.168.100.152 -> 192.168.100.154    104 MB/s
192.168.100.152 -> 192.168.100.154    102 MB/s
192.168.100.152 -> 192.168.100.154    104 MB/s
192.168.100.152 -> 192.168.100.154    101 MB/s
192.168.100.152 -> 192.168.100.154    102 MB/s
192.168.100.152 -> 192.168.100.154    101 MB/s
192.168.100.152 -> 192.168.100.154    104 MB/s
----------------------------------------------
Max: 113 MB/s    Min: 101 MB/s    Avg: 103.8 MB/s

192.168.100.152 <- 192.168.100.154    42.2 MB/s
192.168.100.152 <- 192.168.100.154    41.2 MB/s
192.168.100.152 <- 192.168.100.154    41.1 MB/s
192.168.100.152 <- 192.168.100.154    43.0 MB/s
192.168.100.152 <- 192.168.100.154    42.3 MB/s
192.168.100.152 <- 192.168.100.154    42.3 MB/s
192.168.100.152 <- 192.168.100.154    40.2 MB/s
192.168.100.152 <- 192.168.100.154    40.9 MB/s
192.168.100.152 <- 192.168.100.154    41.3 MB/s
192.168.100.152 <- 192.168.100.154    42.0 MB/s
-----------------------------------------------
Max: 43.0 MB/s    Min: 40.2 MB/s    Avg: 41.65 MB/s

Я поняття не маю, чому він досяг максимуму в 113 Мб / с на першому тестовому циклі, локальному та віддаленому. Він утримував цю швидкість протягом усього тестового пробігу, графік був майже рівним при 113 Мб / с. Як і раніше, я використовував інтервал 60 секунд для кожного пробігу. На наступному пробігу він знизився до 104 Мб / с.

Як ви можете зрозуміти за цими значеннями, у мене все ще є така ж пропускна здатність з цим адаптером Intel, як і з вбудованим адаптером Realtek. Тому я вважаю, що це безпечно сказати, що це не має нічого спільного з самим адаптером. Таким чином, ми можемо перестати звинувачувати RTL8111B як неповноцінний / менший чіп, ніж RTL8111C, знайдений на іншій материнській платі. Це все більше нагадує проблему програмного забезпечення / ОС / конфігурації або всі три речі одночасно.

Оновлення 8 - Чудові результати з Ubuntu LINUX

Вичерпавши всі інші варіанти, я нарешті вирішив запустити кілька тестів з Linux, і я отримав чудові результати. Я використовував систему Ubuntu Linux 13.10 Live та Iperf для Linux (версія 2.0.5-3) на локальній та віддаленій машині. Ось результати.

=======================================================
REALTEK 8111C <-> REALTEK 8111B | IPERF ON UBUNTU LINUX
=======================================================

local: 192.168.100.152
remote: 192.168.100.151

192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
192.168.100.152 -> 192.168.100.151    112 MB/s
----------------------------------------------
Max: 112 MB/s    Min: 112 MB/s    Avg: 112 MB/s

192.168.100.152 <- 192.168.100.151    110 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    110 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
192.168.100.152 <- 192.168.100.151    111 MB/s
----------------------------------------------
Max: 111 MB/s    Min: 110 MB/s    Avg: 110.8 MB/s

Місцевий (завантаження, завантаження, очікування) ...

Як ви бачите, я отримую однакову пропускну здатність в обох напрямках при використанні Ubuntu. Це тому, що я використовую ту саму ОС на обох машинах, чи це щось інше? Я отримав би однакову пропускну здатність, якби на обох машинах були встановлені однакові версії Windows? Я не розумію, чому це було б важливо, якщо я використовую трохи застарілу версію Windows, а саме Vista, на одній машині та останню версію на іншому? ... Я маю на увазі, що Vista все ще є поточною та підтримуваною ОС та підтримується Microsoft . Windows XP - інша історія.

Але я знаю, що вони роблять усе можливе, щоб вбити Вісту. Наприклад, остання Office 2013 навмисно не підтримується в Windows Vista. Я впевнений, що Microsoft бажає, щоб у Vista ніколи не бувало. Так само, як вони хочуть, щоб Windows 8.0 ніколи не бував. Але я зазвичай настільки ж наполегливий, як і вони, і я не оновлюю встановлення Windows, поки я абсолютно не повинен.

Отже, питання полягає в тому, як отримати однакову пропускну спроможність в обох напрямках з двома різними версіями Windows. Windows Vista повинна мати швидкість гігабіту - це не 20-річна ОС чи щось таке, це не Windows 95, про яку ми говоримо. Vista - це сучасна ОС. Я ще не перевіряв роботу однакової версії Windows на обох машинах. Можливо, є різниця у впровадженні TCP або щось серед двох версій ОС. Якщо так, то, ймовірно, я змушуватимуться оновити машину Vista. Або це, або перехід на Linux. Я не готовий платити більше за менше. Чому мені доведеться оновити Windows просто для отримання пропускної спроможності Gigabit в обох напрямках? ...

Оновлення 9 ...

Кабель

Я спробував перевернути кабель. Я отримав ті ж результати, що і раніше. Я також придбав новий патч Cat 6 і випробував цей. Результати тесту на пропускну здатність були однаковими. Таким чином, тут не проблема. Я використовував лише попередньо скасовані / формовані патч-кабелі. Тож електропроводка повинна бути правильною. Але згодом я планую припинити власні монтажні кабелі.

FW і AV

Що стосується брандмауера (FW) та антивірусу (AV), я не використовую сторонніх програм FW чи AV. У мене є лише брандмауер Windows та Essentials безпеки. Я їх відключив на обох машинах. Результати тесту на пропускну здатність були такими ж, як і раніше.

Тест швидкості локальної мережі

На локальній машині я встановив LAN Speed ​​Test Lite 1.3. Я вважаю, що тест проводиться між пам'яттю на локальному і дисководом на віддаленій машині. Я не впевнений. Але він запитує шлях спільного доступу до віддаленої машини. Я використовував o $ share на віддаленому.

Upload: 427 Mbps
Download: 420 Mbps

Я не дуже вірю цим результатам. Якщо ви подивитесь на графік, то можна побачити, що він дуже відрізняється протягом всього тесту. Тест був "послідовним" тестом, тобто: спочатку написати (завантажити) тест, а потім прочитати (завантажити) тест. Очевидно, що якщо ви робите тест одночасного завантаження / завантаження, загальна пропускна здатність буде нижчою. Але мене не цікавлять такі тести. Поки що я робив "послідовні" тести з обома тестами передачі файлів у Windows (обмін файлами / smb) та Iperf.

Я не робив жодної пам’яті для тестів пам’яті за допомогою тесту швидкості локальної мережі, тому що для використання програми потрібна програма з назвою LST Server, і для її використання потрібна реєстрація.

Оновлення 10 ...

Тести дискових накопичувачів

Я використовував Crystal Disk Mark 3.0.3 для тестування дисководів. Ось результати.

Local disk: 118 MB/s read, 113 MB/s write
Remote disk: 70 MB/s read, 69 MB/s write

Це послідовна швидкість читання і запису на основі 5 пробігів і завантаження 1000 Мб.

Це локальний диск (позначка диска, читання, запис) ...

І це віддалений диск ...

Але я цього не розумію ... ці результати здаються суперечливими.

Гаразд, локальний диск може читати зі швидкістю 118 Мб / с, що дозволить завантажувати повідомлення приблизно у 100 Мб / с. Але віддалений диск не зможе його отримати, якщо він здатний записувати лише 69 Мб / с. Але якимось чарівним поворотом я все-таки отримую в середньому трохи більше 100 Мб / с.

Йти навпаки має більше сенсу. Якщо віддалений диск може читати зі швидкістю 70 Мб / с, а локальний диск може писати зі швидкістю 113 МБ / с, то завантаження не повинно бути швидшим, ніж 70 Мб / с. У середньому я отримую близько 40 Мб / с. Це здавалося б розумним.

Тому я нічого не можу зробити з цих результатів. Я маю на увазі, що диск на локальному комп'ютері ледь використовується. Це також диск, який містить ОС, і це єдиний розділ у цій системі. У той час як віддалений диск майже повний, він також розділений декількома розділами. Однак він не використовується для ОС. Тут я вибрав літеру диска O:для тесту, оскільки це розділ з більшою кількістю вільного місця.

(Зверніть увагу, що я використовував букву диска C:в попередніх тестах, який знаходиться на повністю окремому дисководі Seagate, який містить ОС на віддаленій машині. Тому ці показання не порівнянні.)

Запишіть кешування

Якщо увімкнено кешування запису на диску, я отримав ці результати.

Local to remote: 106 MB/s
Remote to local: 42.2 MB/s

Потім я відключив кешування запису на всіх дисках на віддаленому та на локальному диску.

Я не перезавантажувався, оскільки не вимагалося перезавантаження, щоб зміни вступили в силу. Потім я отримав такі результати.

Local to remote: 106 MB/s
Remote to local: 42.1 MB/s

Змін практично не було. Ні перезавантаження, ні перезавантаження не вимагалося.

Пакет QOS

Потім я перейшов до відключення QOS Packet Scheduler для відповідного адаптера на віддаленій машині, а потім на локальній машині.

Local to remote: 107 MB/s
Remote to local: 41.9 MB/s

Тут немає істотних змін. Знову ж, ні перезавантаження, ні перезавантаження не вимагали.

Пакети Jumbo

Потім я ввімкнув джомбо-пакети, я використав налаштування 4 Гб, оскільки 4 КБ - це найбільший розмір MTU, який підтримується на обох машинах.

Local to remote: 105 MB/s
Remote to local: 33.3 MB/s

Тепер тут завантаження (локальне на віддалене) не вплинуло, але пропускна здатність завантаження значно зменшилась. Ніякої перезавантаження не вимагалося, але я вирішив перезавантажити обидві машини все одно, тільки для гарної міри. Потім я знову зробив ті ж тести і отримав ці результати.

Local to remote: 117 MB/s
Remote to local: 33.2 MB/s

Тож завантаження зараз ще швидше, але завантаження все ж відбувається повільніше, ніж було до того, як я вніс ці зміни, навіть після перезавантаження. Я б очікував, що вони обидва трохи підняться. Що це значить?

На основі вашої відповіді:

@ewhac Розмір вікна TCP на локальній машині зазвичай відрізняється від розміру вікна на віддаленій машині. Значення за замовчуванням - 0,06 МБ на локальному (виграш 8) та 0,01 МБ на віддаленому (Vista). Чи повинні вони мати однакове значення? Як я можу його відгадати MSS? Це був би перемикач -m ("максимальний розмір сегмента")? Зазвичай я нічого не встановлюю. Навіщо мені це робити? - Семмі 30 листопада о 21:39

Розмір вікна TCP являє собою максимальну кількість даних, на яку стек TCP стискатиме дротяну штору перед зупинкою та очікуванням отримання підтверджень від віддаленої машини - іншими словами, максимальний обсяг невстановленого трафіку на дроті. Той факт, що вікно TCP на машині Vista набагато менше, ніж на машині Windows Se7en, підтримує теорію, що ви недостатньо наповнюєте трубу перед тим, як зупинятись та чекати ACK.

Тому перше, що я спробую, - це збільшити розмір вікна TCP на машині Vista за допомогою -wаргументу. 0,01 МБ - дещо непомітна одиниця; Я здогадуюсь це 16KiB. Тож почніть з 16KiB і запустіть тест:

iperf -c -w 16K ...

Подвойте розмір вікна та повторіть тест:

iperf -c -w 32K ...

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

Як було зазначено раніше, вам потрібно буде змінити розмір вікна TCP в iperf, щоб отримати більш високу пропускну здатність по швидкостям низьких затримок. Різні версії Windows (або iPerf) можуть мати різні розміри вікон за замовчуванням. Спробуйте «-w 256K» , щоб почати з на обох клієнтом і сервером.

Чи можете ви підтвердити напрямок стрілки своїх діаграм? В iPerf дані висуваються з клієнта на сервер (навпроти того, що я зазвичай думаю).

Ви можете виключити жорсткі диски як причину, оскільки iPerf не торкається жорстких дисків.

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

Переконайтеся, що в обох НІК ввімкнено велике завантаження (LSO) та велике завантаження (LRO). Деякі драйвери NIC використовують різні назви (або кілька варіантів, які керують такою поведінкою), тому вам, можливо, доведеться полювати навколо. Зазвичай за замовчуванням є їх увімкнено.

Я думаю, що вам потрібно прочитати трохи більше про те, як працює iperf. Якщо ви не встановите правильний розмір вікна tcp, результати будуть сильно відрізнятися. Я вважаю, його перемикач -w. Цей веб-сайт допоможе підрахувати оптимальний розмір вікна TCP. Вам потрібно знати RTT та пропускну здатність для його обчислення. http://www.kehlet.cx/docs/tcpwin.php

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

Кілька пунктів, які можуть вам допомогти. IP-стек TCP тепер реалізується по-різному в публікаціях Windows 7. Я б уважно придивився до моїх оптимізацій TCP, можливо, між вашими двома скриньками не так багато, але все ж варто налаштувати деякі налаштування на вашому вікні Vista.

Використання netsh int tcp set global congestionprovider = ctcp знецінено. Для встановлення або зміни захисника перевантажень слід використовувати наступну команду:

читайте статтю тут: http://forums.speedguide.net/showthread.php?280646-When-will-TCP-Optimizer-support-Windows-8-amp-Windows-Server-2012

netsh int tcp набір додатковий звичай 300 10 ctcp відключений 50 Потім введіть: netsh int tcp set додатковий звичай

Для отримання детальної інформації про вищевказану команду просто введіть: netsh int set додатковий

Щоб перевірити, який постачальник перевантаженості поточного потоку використовуєте, скористайтеся наступним: netsh int tcp показати додатковий

Але лише Win Server 2012 може створити власні шаблони CTCP, можливо, проблема.

Також фактором автоматичного масштабування може бути фактор.

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

Інша думка полягає в тому, що розміри пакетів записуються на жорсткий диск .. Якого розміру ваші сектори жорсткого диска відформатовані до 512b ~ 64K, це може бути кешування вузького місця. Варто врахувати при використанні швидкостей GBit - або замість тестування на SSD диску!

Ви подивилися, як включити пакети Jumbo (якщо це стосується ваших NIC)

Чудові результати з Ubuntu LINUX

Це звучить досить звично ... ви отримуєте незрозуміло погану iperfпродуктивність в Windows, але те ж саме обладнання добре працює з Linux.

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

Тож якщо ви хочете знати, чому ви отримуєте такі погані показники, не шукайте далі, ніж додаток.

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

Ознайомтесь з інформацією про MMCSS та мережеве дроселювання: http://blogs.technet.com/b/markrussinovich/archive/2007/08/27/1833290.aspx

Це можна змінити відповідно до цих інструкцій: http://support.microsoft.com/kb/948066

Я сумніваюся, що це причина в цьому випадку, оскільки пропускна здатність, ймовірно, буде нижчою, але після довгого удару головою об стіну зі своїми проблемами пропускної здатності на Vista, я виявив, що це було причиною. Я встановив NetworkThrottlingIndex на 70, і я нарешті отримав очікувану пропускну здатність.

Одне, що ви не пробували, - це видалити віддалене диференціальне стиснення на Vista.

Моє мислення мотивоване великим використанням процесора у Vista. Можливо, мережевий драйвер Vista не знає, як завантажити його на мережеву карту, тоді як Windows 8 робить це набагато ефективніше.

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

Але в двох словах, зніміть прапорець Remote Differential Compressionу Панелі керування -> Програми та функції -> Увімкнення та вимкнення функцій Windows, а потім перезавантажте систему.

Раніше я переслідував свій хвіст з точно такою ж проблемою на деякий час! Повільна швидкість передачі в одному напрямку, в моєму випадку вихідна (висхідна лінія).

Windows 7 Pro, Celeron J1800 з вбудованою карткою lantek Realtek Gigabit 8111C. QNAP 453a та MacBook Pro на іншому кінці.

Коли вимірювались через Iperf3, я отримував 112 Мбіт / с з моїм набором Windows 7 як клієнт (використання процесора на рівні 25-30%). І лише 39-41 Мбіт / с, якщо встановлено як сервер, з великим використанням процесора між 50-100%. Настільки погано, що ПК замерзне під час тестування пропускної здатності.

Регулярна передача файлів обмежена максимальною швидкістю 45 Мбіт / с незалежно від того, завантажував я або завантажував файли в свій NAS або мій MAC.

Я отримував не більше 35-45 мегабайт в секунду. Досить засмучує!

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

Деякі з вас можуть сказати, просто видаліть старий драйвер та встановіть новий. Просто, а? Я намагався і пробував, Мені це не вийшло.

Ось моє рішення:

Встановлені вікна з нуля з драйверами OEM з веб-сайту виробника. Я також зробив наступне:

У розділі Диспетчер пристроїв / картка Лан / Додаткові параметри / Відключити все, крім КОНТРОЛЮ ПОТОК.

У розділі Особливості Windows вимкнути віддалене диференційоване стиснення.

Зараз середня швидкість між 80-100 Мбіт / с.

Вибачте за низьку якість фото.

У Linus з Linus Tech Tips на Youtube була така ж проблема, і я вибачаюся, але забув, яке рішення було. Це недавнє (станом на 20.04.2016) відео, і я можу помилятися, але я думаю, що в кінцевому підсумку це був випадок, коли один потік процесора є обмежуючим фактором, тож якщо у вас є старіше обладнання та ви намагаючись вразити 1 Гбіт / с, саме ця процесор є проблемою, якщо вона завантажує основну частину роботи в процесор, що робить більшість бортових NIC в ці дні. Я можу помилитися, це недавнє його відео, настійно рекомендую вам перевірити його потік. Оскільки це варто, я зіткнувся з тією ж проблемою на своєму гігабітному підключенні до Інтернету.