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

Моя домашняя сеть - чистый гигабит с устройствами, которые поддерживают большие кадры размером не менее ~ 9000 байт. Увеличение значения параметра MTU jumbo frame в 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: «Включить»
Не удается выяснить, какой размер большого кадра он на самом деле поддерживает, кажется, по крайней мере 9000

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

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

TP-LINK TL-SG1008D
Jumbo Frames (технические характеристики): 9 КБ (на их сайте написано 15 КБ, но выглядит как другое устройство)

сервер

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

Пакеты для чтения файлов из Synology в Client.
Размер: большинство из них составляют 9014 байт (в обоих направлениях).
Флаги IP: не фрагментировать
Обнаружен Wireshark: ложная повторная передача TCP, предыдущий сегмент TCP не перехвачен, TCP вышел из строя, быстрая повторная передача TCP, и нормальные (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 на клиенте; все размеры являются размерами проводных байтов)
[9019, ∞] запрос отправлен, ответ отправлен, ответ не получен
[9015, 9018] фрагментированный IP-запрос (вероятно, фрагментирован Synology, пинг busybox не имеет опция без фрагмента, поэтому сложно сказать)
[60, 9014] нефрагментированный IP
[0, 59]? (невозможно сгенерировать, поскольку пинг busybox помещает как минимум 18 байтов плюс 42-байтовые заголовки)

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

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

ethernet synology throughput colithium
источник

Вам нужно подать заявку в службу поддержки с синологией. У меня нет опыта работы с synology, поэтому я не знаю, есть ли дополнительные настройки, где вы можете увеличить размер буфера памяти, но это, вероятно, то, что нужно. Лично я, как правило, получаю 920 Мбит и вообще не использую большие кадры. Просто имейте общий неуправляемый сетевой переключатель.

Кибернард

Производительность чтения Synology снижается благодаря Jumbo Frames более 6000