☰

Укороченная версия

tag-icon • tag-icon ethernet throughput
Укороченная версия

Укороченная версия

Моя домашняя сеть — это чистый гигабит с устройствами, которые поддерживают jumbo-фреймы размером не менее ~9000 байт. Увеличение параметра MTU jumbo-фрейма на Synology до 6000 (байт) увеличивает производительность (810 Мбит/с при записи и 945 Мбит/с при чтении). Установка значения 7000 уничтожает только производительность чтения (которая снижается до 4 Мбит/с); производительность записи остается высокой.

Это неожиданно, поскольку большинство проблем с большими кадрами не имеют направленности, связанной с ними, и обычно имеют тип «все или ничего» (пакеты отбрасываются на коммутаторе независимо от того, откуда они пришли). Кажется, нетлюбойIP-фрагментация вообще происходит, но уровень TCP действительно недоволен. Что может быть причиной этого асимметричного/нестабильного поведения и как мне исправить это, чтобы поддерживать полный MTU в 9000 байт, который должно поддерживать все мое оборудование?

Длинная версия

Это мои отредактированные заметки, сделанные в процессе попыток разобраться в этом вопросе.

Клиент

Контроллер семейства Realtek PCIe GBE RTL8167
Jumbo Frame: 9 КБ MTU

$ netsh interface ipv4 show subinterfaces
   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
  9198                1   32501506   11275394  Local Area Connection

(похоже, 9198 не включает 14-байтовый заголовок Ethernet)

$ ping -l 1500 -f 192.168.1.84

(наблюдается с Wireshark, запущенным на клиенте; все размеры являются размерами байтов провода)
[9213, ∞] не отправлено хостом (потребуется фрагментация)
[9019, 9212] отправлено, но нет ответа
[9015, 9018] фрагментированный ответ IP
[42, 9014] нефрагментированный IP
[0, 41] ? (невозможно сгенерировать, так как заголовки eth+IP+ICMP = 14+20+8 = 42 байта)

Маршрутизатор (часть коммутатора)

Asus RT-AC68U — прошивка 3.0.0.4.378_4585
Включить Jumbo Frame: «Включить»
Не могу понять, какой размер jumbo frame он фактически поддерживает, похоже, не менее 9000

Он фрагментирует запросы ping от Клиента ровно по 1514 байтам (но пингование маршрутизатора может привести к срабатыванию его режима маршрутизатора WAN, а не режима коммутатора LAN?)

Неуправляемый коммутатор

TP-LINK TL-SG1008D
Jumbo Frames (спецификации): 9 КБ (на их веб-сайте указано 15 КБ, но похоже, что это другое устройство)

Сервер

Synology DS1815+ -- DSM 5.2-5565 Обновление 1
Jumbo Frame: 9000

Пакеты чтения файлов от Synology к клиенту
Размер: большинство из них 9014 байт (в обоих направлениях)
Флаги IP: не фрагментировать
Wireshark обнаружил: TCP Spurious Retransmission, TCP Previous segment not capture, TCP Out-Of-Order, TCP Fast Retransmission и обычные (9014 байт) пакеты
Длина ответа при чтении пакетов протокола SMB2 over-NetBIOS: 65 536 (~8 сегментов TCP)

$ ifconfig
bond0     Link encap:Ethernet  HWaddr --:FF
          inet addr:192.168.1.84  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addrs: --/64 Scope:Link, --/64 Scope:Global, --/64 Scope:Global
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:85 dropped:0 overruns:0 frame:85
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:237 GiB  TX bytes:117 GiB

eth2      Link encap:Ethernet  HWaddr --:00
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:19 dropped:0 overruns:0 frame:19
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:236 GiB  TX bytes:83 GiB

eth3      Link encap:Ethernet  HWaddr --FF
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:9000  Metric:1
          RX packets:lots errors:66 dropped:0 overruns:0 frame:66
          TX packets:lots errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1 GiB  TX bytes:33 GiB

eth2 и eth3 связаны с помощью адаптивной балансировки нагрузки (без поддержки коммутатора)

$ ping -c 5 -s 1500 192.168.1.82

(наблюдается с Wireshark, запущенным на Client; все размеры являются размерами байтов провода)
[9019, ∞] запрос отправлен, ответ отправлен, ответ не получен
[9015, 9018] фрагментированный запрос IP (вероятно, фрагментирован Synology, у busybox ping нет опции без фрагментации, поэтому трудно сказать)
[60, 9014] нефрагментированный IP
[0, 59] ? (невозможно сгенерировать, поскольку busybox ping помещает минимум 18 байт плюс 42 байта заголовков)

Разные данные

  • Изменение MTU клиента до 8 КБ не помогло
  • Скорость чтения сервера резко падает при изменении MTU сервера с 6000 (отлично, 945 Мбит/с) до 7000 (ужасно, 4 Мбит/с)
  • Скорость записи сервера практически не изменяется при любых настройках MTU сервера (всегда от 700 до 825 Мбит/с)
  • Synology имеет связанную сеть (2 из 4 портов)
  • Все кабели Cat6 или Cat5e.

решение1

Обновите прошивку

По моему опыту, Synology исправляет множество проблем в каждой версии прошивки, а та, которую вы используете, почти четырехлетней давности. Я не читал заметки о выпуске, но, похоже, есть много возможностей для исправления ошибки Jumbo-фрейма с тех пор.

Тест с прямым подключением

Подключите тестовую машину напрямую к Synology (назначьте статические IP-адреса в той же подсети) с помощью новых соединительных кабелей и повторите тесты. Это устранит проблемы с кабелями и коммутаторами, а также любые другие проблемы с оборудованием и конфигурацией. Если проблема останется, запустите тесты на другом компьютере. Если она все еще останется, то это, безусловно, NAS.

Если проблема исчезнет во время теста прямого подключения, попробуйте сначала заменить коммутатор, а затем кабели. Вы не показали соединения, поэтому я предполагаю, что это просто TPLINK между тестовой машиной и NAS.

Связанный контент