Время сериализации и сериализации в 40G / 10G и 100G / 25G Ethernet

Недавно я принимал участие в дискуссиях о требованиях с минимальной задержкой для сети Leaf / Spine (или CLOS) для размещения платформы OpenStack.

Системные архитекторы стремятся к минимально возможному RTT для своих транзакций (блочное хранилище и будущие сценарии RDMA), и утверждается, что 100G / 25G предлагает значительно меньшие задержки сериализации по сравнению с 40G / 10G. Все вовлеченные лица знают, что в сквозной игре намного больше факторов (любой из которых может повредить или помочь RTT), чем просто задержки сериализации сетевых адаптеров и портов коммутатора. Тем не менее, тема о задержках сериализации продолжает всплывать, поскольку их трудно оптимизировать без преодоления, возможно, очень дорогостоящего технологического разрыва.

Слишком упрощенное (без учета схем кодирования) время сериализации можно рассчитать как число бит / битрейт , что позволяет нам начинать с ~ 1,2 мкс для 10G (см. Также wiki.geant.org ).

For a 1518 byte frame with 12'144bits,
at 10G (assuming 10*10^9 bits/s), this will give us ~1.2μs
at 25G (assuming 25*10^9 bits/s), this would be reduced to ~0.48μs 
at 40G (assuming 40*10^9 bits/s), one might expect to see ~0.3μs
at 100G (assuming 100*10^9 bits/s), one might expect to see ~0.12μs

Теперь для интересного. На физическом уровне 40G обычно делается как 4 полосы по 10G, а 100G - как 4 полосы по 25G. В зависимости от варианта QSFP + или QSFP28, это иногда делается с 4 парами волокон, иногда оно разбивается лямбдами на одну пару волокон, где модуль QSFP самостоятельно выполняет некоторое xWDM. Я знаю, что есть спецификации для 1x 40G или 2x 50G или даже 1x 100G, но давайте пока оставим их в стороне.

Чтобы оценить задержки сериализации в контексте многолинейных 40G или 100G, необходимо знать, как сетевые адаптеры 100G и 40G и порты коммутатора фактически, так сказать, «распределяют биты по (множеству) проводам (ам)». Что здесь делается?

Это немного похоже на Etherchannel / LAG? NIC / switchports отправляют кадры одного «потока» (читай: один и тот же результат хеширования любого алгоритма хеширования, который используется в какой области кадра) по одному данному каналу? В этом случае мы ожидаем задержки сериализации, такие как 10G и 25G, соответственно. Но, по сути, это сделало бы канал 40G просто LAG 4x10G, уменьшая пропускную способность одного потока до 1x10G.

Это что-то вроде побитовой круговой? Каждый бит распределен по четырем (под) каналам? Это может фактически привести к меньшим задержкам сериализации из-за распараллеливания, но вызывает некоторые вопросы о доставке по порядку.

Это что-то вроде кругового робина? Целые кадры Ethernet (или другие подходящие по размеру куски битов) передаются по 4 каналам, распределенным в виде циклического перебора?

Это что-то еще, например ...

Спасибо за ваши комментарии и указатели.

Часть, которая выполняет деление на несколько дорожек, называется подуровнем физического кодирования в стандарте IEEE 802.3ba. Эта презентация Гэри Николла дает хороший обзор этого.

Краткое объяснение состоит в том, что данные разделены на несколько полос в блоках по 64 бита каждый ( кодируются по проводам как 66 бит для восстановления тактовой частоты). Поэтому, как только размер пакета превышает N * 64 бит (= 32 байта для 4 линий), он может полностью использовать все линии. Будет некоторая задержка в кодировании, но это, вероятно, зависит от реализации.

Эта диаграмма из презентации, представленной выше:

Ты слишком много думаешь.

Количество используемых полос не имеет большого значения. Независимо от того, передаете ли вы 50 Гбит / с по 1, 2 или 5 линиям, задержка сериализации составляет 20 пс / бит. Таким образом, вы получите 5 бит каждые 100 пс, независимо от используемых дорожек. Разбиение данных на дорожки и рекомбинация происходит в подуровне PCS и невидимо даже в верхней части физического уровня. Независимо от вашей ситуации, не имеет значения, сериализует ли PHY 100G 10 битов последовательно по одной полосе (10 пс каждая, всего 100 пс) или параллельно по 10 полосам (100 пс каждая, всего 100 пс) - если только вы не воссоздание этого PHY.

Естественно, 100 Гбит / с имеют половину задержки 50 Гбит / с и т. Д., Поэтому, чем быстрее вы сериализуетесь (поверх физического уровня), тем быстрее передается кадр.

Если вас интересует внутренняя сериализация в интерфейсе, вам нужно взглянуть на вариант MII, который используется для класса скорости. Тем не менее, эта сериализация происходит на лету или параллельно с фактической сериализацией MDI - она ​​занимает минуту времени, но это зависит от фактического оборудования и, вероятно, невозможно предсказать (что-то около 2-5 пс будет быть моим предположением для 100 Гбит / с). Я бы на самом деле не беспокоился об этом, так как здесь задействованы гораздо более важные факторы. 10 пс - это порядок задержки передачи, который вы получите от дополнительных 2 миллиметров (!) Кабеля.

Использование четырех полос 10 Гбит / с каждая для скорости 40 Гбит / с - это НЕ то же самое, что объединение четырех каналов 10 Гбит / с. Канал со скоростью 40 Гбит / с - независимо от количества линий - может передавать один поток со скоростью 40 Гбит / с, который не может получить канал LAGged со скоростью 10 Гбит / с. Кроме того, задержка сериализации в 40G составляет всего 1/4 от 10G.