Сети и протоколы
Физический канал: чтение кода и трасс
Суть Прочитай расчёт BDP, дамп счётчиков ethtool, конфиг SQM-шейпинга и сумму переподписки leaf — затем выбери прочтение, которое сделал бы senior.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеПроблемы физического канала диагностируются в счётчиках, конфигах и прикидках на салфетке — не в прозе. Прочитай каждый артефакт, предскажи поведение и выбери ход, который senior делает первым.
Цель
Потренируй цикл, который запускаешь на каждом инциденте линка: прочитай число или конфиг, реши, борешься ли ты с физикой или с неверной конфигурацией, и возьми верный рычаг.
Сниппет 1 — приёмное окно на толстой трубе
# Межконтинентальное волокно: канал 10 Гбит/с, RTT 160 мс (NYC -> Sydney)
bandwidth_bps = 10_000_000_000
rtt_s = 0.160
bdp_bytes = bandwidth_bps * rtt_s / 8 # байт в полёте при насыщении
rcv_window = 64 * 1024 # legacy-дефолт, без window scaling
print(bdp_bytes) # 200_000_000 -> 200 МБ
print(bdp_bytes / rcv_window) # ~3125 Викторина
Completed
При BDP = 200 МБ и приёмном окне 64 КБ какой throughput реально получит это соединение на канале 10 Гбит/с и почему?
Heads-up Приёмное окно — жёсткий потолок на байты в полёте, независимо от скорости NIC. С 64 КБ нельзя иметь больше 64 КБ неподтверждённых, поэтому линк простаивает бо́льшую часть каждого RTT.
Heads-up На пути с высоким BDP окно прямо ограничивает throughput: байты-в-полёте ÷ RTT. Окно много ниже BDP — классический баг недоиспользования: он стоит throughput, а не задержки.
Heads-up Распространение задаёт RTT, но здесь throughput ограничен маленьким окном, а не полом. Window scaling чинит это без изменения пути.
Сниппет 2 — счётчики интерфейса
$ ethtool -S eth0 | grep -E 'rx_crc|rx_errors|link'
rx_crc_errors: 48213
rx_errors: 48213
$ ethtool eth0 | grep -E 'Speed|Duplex'
Speed: 1000Mb/s
Duplex: Full Викторина
Completed
Линк согласовал 1 Гбит/с full-duplex, но rx_crc_errors стабильно растёт. Что это значит и какое первое действие?
Heads-up CRC-ошибки про целостность сигнала на среде, а не про загрузку CPU. Занятый CPU показывает drops/overruns, а не невалидные frame check sequences.
Heads-up Провал CRC означает, что биты физически изменились в пути до того, как драйвер их увидел. Перезагрузка драйвера не починит испорченный сигнал на кабеле.
Heads-up Ненулевые CRC-ошибки означают, что данные тихо портятся на line rate и должны ретранслироваться; они никогда не нормальны на здоровом линке и должны быть доведены до корневой причины.
Сниппет 3 — конфиг SQM-шейпинга
# tc / CAKE на WAN-egress домашнего роутера с аплинком 40 Мбит/с
tc qdisc replace dev wan root cake bandwidth 36Mbit docsis
# ^^^^^^^ зашейплено НИЖЕ line rate 40 Мбит/с Викторина
Completed
Почему шейпер CAKE выставлен на 36 Мбит при аплинке 40 Мбит/с, а не на полные 40, и что делает ключевое слово `docsis`?
Heads-up Установка на line rate оставляет bottleneck в негабаритном буфере модема, где у CAKE нет контроля — и bufferbloat возвращается. Шейп ниже line rate — весь смысл SQM.
Heads-up CAKE не резервирует статически слот под голос, а `docsis` — это компенсация фрейминга, не класс приоритета. Запас существует, чтобы держать bottleneck внутри роутера.
Heads-up Это egress (upload) qdisc — ровно то направление, что насыщает бэкап. Шейпинг egress ниже line rate и укрощает upload-bufferbloat.
Сниппет 4 — сумма переподписки leaf
# Один leaf-свитч в GPU-pod
downlinks_to_servers = 8 * 200e9 # 8 серверов x 200 Гбит/с RoCE NIC
uplinks_to_spines = 2 * 400e9 # 2 x 400 Гбит/с до spine
oversub = downlinks_to_servers / uplinks_to_spines
# = 1.6 Тбит/с / 0.8 Тбит/с = 2.0 -> 2:1 Викторина
Completed
Leaf переподписан 2:1. Для задачи AllReduce на 64 GPU что это предсказывает и как достичь non-blocking?
Heads-up GPU-коллективы — east-west и all-to-all — худший случай для переподписки. 2:1 прямо вдвое режет полосу для AllReduce, поэтому задача и стопится.
Heads-up Больше GPU увеличивают all-to-all-трафик, усугубляя bottleneck. Фикс — больше uplink-полосы на leaf, а не больше endpoint'ов за теми же аплинками.
Heads-up Уполовинивание скорости NIC снижает спрос, но и вдвое режет полосу на GPU — ты прячешь коэффициент, делая всё медленнее. Non-blocking значит поднять uplink-ёмкость под downlink'и, а не калечить серверы.
Итог
Каждый артефакт указывал на одно и то же разделение: окно 64 КБ на пути с BDP 200 МБ — это баг throughput (подними окно, а не кабель); растущий rx_crc_errors — испорченный сигнал (замени кабель/SFP, никогда не игнорируй); CAKE, зашейпленный ниже line rate, переносит bottleneck-очередь туда, где ты можешь её дисциплинировать; а leaf 2:1 режет all-to-all-коллектив вдвое. Прочитай число, реши физика-против-конфига, затем возьми соответствующий рычаг.