Часи серіалізації та серіалізації в 40G / 10G та 100G / 25G Ethernet


15

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

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

Трохи спрощений (не виключаючи схеми кодування), час серіалізації можна обчислити як кількість біт / бітову швидкість , що дозволяє нам починати з ~ 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 необхідно знати, як NIC 100G і 40G та комутаційні порти насправді "розподіляють біти на (набір) проводів (ів)", так би мовити. Що тут робиться?

Це трохи схоже на Etherchannel / LAG? NIC / комутатори передають кадри одного "потоку" (читай: той самий результат хешування будь-якого алгоритму хешування, який використовується в якій області кадру) через один заданий канал? У цьому випадку ми очікуємо затримки серіалізації, як 10G та 25G відповідно. Але по суті, це зробить 40G-ланкою лише LAG 4x10G, зменшивши пропускну здатність одного потоку до 1x10G.

Це щось на кшталт дотепного круглолиця? Кожен біт круглобільно розподіляється по 4 (під) каналам? Це може призвести до менших затримок серіалізації через паралелізацію, але викликає деякі питання щодо доставки замовлення.

Це щось на кшталт обрамлення круглої камери? Цілі кадри Ethernet (або інші шматочки біт відповідної величини) надсилаються по 4 каналам, розподіленим способом круглої роботи?

Це щось інше цілком, наприклад ...

Дякуємо за ваші коментарі та вказівки.

Відповіді:


14

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

Коротке пояснення полягає в тому, що дані поділяються на кілька смуг у блоках по 64 біта кожен ( кодується на дроті як 66 біт для відновлення годинника). Тому, як тільки розмір пакета перевищує N * 64 біт (= 32 байти на 4 смуги), він може повністю використовувати всі смуги. У кодуванні буде деяка затримка, але, мабуть, це стосується конкретної реалізації.

Ця схема представлена ​​вищезгаданою презентацією: Функція підшару фізичного кодування


1
"Буде деяка затримка кодування" , ой о. Тепер ви відкрили ще одну банку глистів! Скільки коштує затримка? Чи впливає це на загальну затримку пакетів? І т. Д.
труба

1
Ах, дякую за це. Як я це розумію, ці "Слова" - це "шматочки біт відповідного розміру", як я виклав це в своєму початковому дописі. Це наближається?
Marc 'netztier' Luethi

1
@ Marc'netztier'Luethi Рівно.
jpa

@pipe Так. На щастя "Усі задіяні особи знають, що факторів набагато більше" :)
jpa

2
@pipe добре, я думаю, що ми залишимо це осторонь. На будь-які виклики, що виникають з цього моменту, я відповім "до тих пір, поки ви надсилатимете достатньо даних відразу (32 байти), щоб дозволити NIC / порт обертатися через чотири смуги, ви отримаєте більш коротку / паралельну затримку серіалізації. ви, хлопці, після стільки ". Звичайно, будь-який напівзапечений кадр Ethernet з IP-заголовком і без корисного навантаження вже не переступить цю межу. Тому: неважливо.
Marc 'netztier' Luethi

16

Ти переосмислюєш.

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

Природно, що 100 Гбіт / с має половину затримки 50 Гбіт / с тощо, тому чим швидше ви серіалізуєте (поверх фізичного шару), тим швидше передається кадр.

Якщо вас цікавить внутрішня серіалізація в інтерфейсі, вам потрібно буде переглянути варіант MII, який використовується для класу швидкості. Однак ця серіалізація відбувається на ходу або паралельно з фактичною серіалізацією MDI - це займає хвилинну кількість часу, але це до фактичного обладнання та, ймовірно, неможливо передбачити (щось поряд із 2-5 п.с. будьте моєю здогадкою для 100 Гбіт / с). Я б насправді не хвилювався з цього приводу, оскільки тут задіяні набагато більші фактори. 10 пс - це порядок затримки передачі, який ви отримаєте від додаткових 2 міліметрів (!) Кабелю.

Використання чотирьох доріжок по 10 Гбіт / с кожна для 40 Гбіт / с НЕ те ж саме, що агрегувати чотири 10 Гбіт / с посилань. Посилання 40 Гбіт / с - незалежно від кількості доріжок - може перевозити єдиний потік 40 Гбіт / с, який LAGged 10 Гбіт / с не може. Також затримка серіалізації 40G становить лише 1/4, ніж 10G.


3
Дякуємо за ваш коментар Отже, ви говорите, що в межах 10/25/40 / 100G правило великого пальця числа "біт на кадр / біт" = затримка серіалізації залишається дійсним, незалежно від того, скільки смуг використовує даний фізичний шар (надайте або взяти деякі граничні відмінності)?
Marc 'netztier' Luethi

6
Так. У цьому відношенні багатолінійна Ethernet дуже відрізняється від агрегованих посилань.
Zac67
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.