Короткий ответ

«Гигабитная сеть» на наклейке коммутатора не равна гигабиту на сессии. Сначала LinkSpeed на обоих концах: часто это 100 Mbps из‑за autoneg/кабеля. Если линк 1 Gbps, а iperf3 даёт 80 Мбит/с — смотрите потери, CPU, offload, TCP window, диск назначения. Не меняйте MTU и не отключайте весь firewall, пока нет цифр: линк, iperf память-память, затем файл.

В примерах LAN 10.0.10.0/24, шлюз 10.0.10.1. Тест гоняйте внутри VLAN, не через NAT/WAN.

Симптомы и как отличить

  • Проводник копирует 8–12 МБ/с (это ~100 Мбит/с);
  • iperf3 900+ Мбит/с, файл — 40 МБ/с: диск/антивирус, не Ethernet;
  • один направление быстро, обратно медленно — асимметрия, Wi‑Fi, или TCP window.

Не путать с высокой задержкой при нормальном throughput и с потерями, которые режут TCP.

Возможные причины

  1. Autoneg: 100/Half или 100/Full вместо 1000/Full.
  2. Кабель не 5e/6, повреждённая пара (линк 100).
  3. Wi‑Fi вместо кабеля.
  4. iperf не запущен, меряют копирование на HDD/USB.
  5. Offload/RSS баг, одно ядро 100%.
  6. Маленькое TCP window, RTT завышен (через VPN).
  7. Дублирующий антивирус на SMB.
  8. Traffic shaping, QoS, 100 Mbps SFP.

Диагностика

1. Скорость линка, не «ощущения»

Get-NetAdapter | Format-Table Name, Status, LinkSpeed, FullDuplex, MacAddress
Get-NetIPConfiguration
ethtool eth0
# Speed: 1000Mb/s  Duplex: Full

Оба конца 1000 Full. Если ПК 100, свитч 1000 — кабель/порт/NIC. Это не TCP window.

2. iperf память-память в LAN

На Ubuntu 10.0.10.20:

iperf3 -s -B 10.0.10.20

С Windows 10.0.10.10 (iperf3 в PATH):

iperf3 -c 10.0.10.20 -t 20 -P 1
iperf3 -c 10.0.10.20 -t 20 -P 4
iperf3 -c 10.0.10.20 -t 10 -R

Ожидание на гигабите: порядка 900–980 Мбит/с на хорошем CPU. 94 Мбит/с ≈ Fast Ethernet. 200–400 при 1G — ищите loss, CPU, Wi‑Fi, вложенный гипервизор.

3. Потери и RTT во время теста

Параллельно:

ping -n 50 10.0.10.20
Get-NetAdapterStatistics

Loss >0% на меди во время iperf — сначала потери. RTT 50 мс в LAN — задержка.

4. Диск vs сеть

Копирование на \\10.0.10.20\share медленное при iperf 900: смотрите диск сервера, очередь, Defender scanning. Обратный тест: приём в /dev/null vs файл.

iperf3 -c 10.0.10.20 -t 10
dd if=/dev/zero of=/tmp/test.bin bs=1M count=2048 conv=fdatasync

5. Offload и окно

Get-NetAdapterChecksumOffload
Get-NetAdapterLso
Get-NetTCPSetting | Select-Object SettingName, AutoTuningLevelLocal, CongestionProvider
Get-NetTCPConnection -RemoteAddress 10.0.10.20 | Select-Object State, Cwnd, *Window*
ss -ti dst 10.0.10.20
ethtool -k eth0

zero window — приёмник не успевает (диск/CPU), не свитч. Не отключайте весь chimney offload пакетом на ферме без теста.

6. Не маска ли врёт

Если узлы «в одной сети» по ошибке маски, трафик идёт через шлюз и NAT — скорость упрётся в WAN. См. ошибочная маска.

Решение

Сценарий A. Линк 100 Mbps

Кабель 8 жил, другой порт, явный autoneg. Оба конца Auto. Не ставьте вручную 1000 Full на ПК при Auto на свитче, если не умеете фиксировать оба.

Сценарий B. Линк 1G, iperf ~100

Ищите второй адаптер, VPN default, метрика. Get-NetRoute 0.0.0.0/0 не должен уводить iperf в туннель.

Get-NetRoute -DestinationPrefix '0.0.0.0/0'
Test-NetConnection 10.0.10.20

Сценарий C. iperf 900, файлы медленные

Диск, антивирус-исключение для служебного share по политике, не «Defender off». SMB multichannel, подпись: измеряйте до/после, не копируйте советы с форумов отключить SMB signing на домене вслепую.

Сценарий D. Offload ломает

Точечно выключите LSO на проблемной паре VM, повторите iperf. Если не изменилось — верните. Документируйте.

Сценарий E. TCP window / дальний RTT

Копирование через VPN в «ту же» подсеть: это не гигабит LAN. Настройте MTU/MSS, не ждите 900 Мбит/с на 10 Мбит/с WAN.

6. Контрольный прогон, который отделяет диск от Ethernet

После LinkSpeed 1 Gbps не спорьте с пользователем «у меня гигабит, копия 8 МБ/с» без двух цифр: iperf память-память и копирование файла. Гоняйте iperf в обе стороны (-R) между 10.0.10.10 и 10.0.10.20, не через 10.0.10.1, если оба в одном VLAN. 940 Мбит/с при файле 40 МБ/с — антивирус, диск, SMB signing/очередь, не «надо сменить свитч». Обратно: iperf 90 Мбит/с при LinkSpeed 1G — ищите 100 Мбит скрытый путь (VPN, USB, второй адаптер, QoS).

Снимите Get-NetAdapterStatistics до и после прогона: discarded, errors. CRC во время теста — кабель/порт, не TCP window. На Ubuntu ethtool -S плюс mpstat 1 20 во время iperf: одно ядро 100% при -P 1 нормально; при -P 4 и всё равно 200 Мбит/с смотрите offload/VM. Не отключайте Windows Firewall «для скорости»: он не режет LAN SMB до 80 Мбит/с на здоровом гигабите. Если копирование идёт через DFS/VPN в «тот же» IP — сначала Find-NetRoute. Широкая маска или /8 VPN превратит гигабит LAN в путь через WAN.

Как проверить, что проблема устранена

Get-NetAdapter / ethtool = 1000 Full. iperf3 в обе стороны близко к гигабиту. Файл: ожидаемая скорость дисков. ping без потерь. Пользовательский сценарий (копирование 1 ГБ) задокументирован по времени.

Если не помогло

  • USB-гигабит даёт 300–400 — ограничение моста USB, не свитч.
  • 2.5G NIC в 1G порту — нормально 1G; не ждите 2.5.
  • Jumbo 9000 на одном конце — MTU.
  • Hyper-V VMQ/RSS: смотрите CPU ready, не только гостевой ethtool.

Профилактика

  • Мониторинг LinkSpeed != 1G на серверах.
  • iperf-базовая линия после монтажа стойки.
  • Кабель 5e/6, не «телефонная» 4 жилы.
  • Не гонять бэкап и пользовательский SMB в один 1G uplink без плана.

FAQ

Почему диспетчер задач показывает 1 Гбит/с, а копия медленная?

График NIC может быть всплесками. Смотрите среднее и диск. iperf отделяет сеть.

Нужны ли jumbo frames для гигабита?

Нет. На 1G выгода небольшая, цена — поломки PMTUD. Не включайте jumbo, пока не умеете держать MTU на всём пути.

Windows показывает 1 Gbps, iperf 200. Кто врёт?

Линк честный. Упираетесь в CPU/loss/VPN/диск. Снимайте -P 4 и CPU.

Можно ли судить по speedtest из браузера?

Это WAN+DNS+HTTP. Для LAN гигабита — iperf между 10.0.10.10 и 10.0.10.20.

Offload всегда включать?

По умолчанию да. Выключайте точечно при доказанном баге (битые checksum, странные drops), не профилактически на всей ферме.