28 марта 2011 г.

Самый эффективный протокол

Недавно попались на глаза расчеты эффективности различных протоколов. Как-то они мне показались не убедительными: то поле в хедере забудут, то из максимального payload не вычтут часть накладных расходов. В общем, решил все пересчитать сам и свести в одну табличку, пригодится в качестве шпаргалки по протоколам.
Может тоже что-нибудь забыл, зато с честной совестью и ощущением полной собственной правоты  ;)

Напомню, "эффективность" считается как отношение максимального объема полезных данных к сумма всех передаваемых данных.

Размеры в байтах.  Аббревиатуры: SOF - Start Of Frame, EOF - End Of Frame, IFG - Iner-Frame Gap.

Поле
Ethernet (Untagged Standard  Frames)
Ethernet (Tagged Standard  Frames)
Ethernet (Tagged Jumbo  Frames)
iSCSI  (Tagged Standard  Frames)
iSCSI (Tagged Jumbo Frames)
FCIP  (Untagged Baby Jumbo  Frames)
FCoE (Untagged Baby Jumbo  Frames)
Fibre Channel (FCP, Class3)
SAS
Preamble
7
7
7
7
7
7
7


Ethernet SOF
1
1
1
1
1
1
1


Ethernet Header
14
16
16
16
16
14
14


IP Header



20
20
20



TCP Header



20
20
20



iSCSI Header



48
48




FCIP Header





24



FCoE Header






16


SOF





4
4
4
4
FC Header





24
24
24

SAS Header








24
Maximum payload
1500
1500
9000
1412
8912
2112
2112
2112
1024
CRC
4
4
4
4
4
4
4
4
4
EOF + Padding





4
4
4
4
IFG
12
12
12
12
12
12
12
24
2
SAS R_RDY and ACK overhead








8
Efficiency
97,98%
97,85%
99,63%
92,11%
98,66%
94,33%
96,39%
97,24%
95,70%

Пятиминутная медитация на таблицу в качестве сатори дает общее понимание структуры протоколов...  Для совсем ленивых прилагаю уже пережеванную картинку...  ;)



В общем, получается, что самый "выгодный" стораджевый протокол все-таки Jumbo iSCSI...
Ему бы еще и остальные достоинства FC или хотя бы FCoE....   ;)   но это тема отдельного разговора.

Кстати, понравилась эта статья про Etherner фреймы, кратко и очень толково. В контексте активного продвижения 10G CEE в мир storage, все дружно вспоминаем уже позабытую. сетевую теорию...  :)

5 комментариев:

  1. Добавьте про Infiniband, пожалуйста.

    ОтветитьУдалить
  2. Прикольная табличка с академической точки зрения )))

    ОтветитьУдалить
  3. К сожалению, с Infiniband я никогда дела не имел :( . Поэтому разбираться в протоколе придется с нуля.
    Сори, но вычитывать различия и условия применения нескольких различных хедеров и двух типов CRC я пока морально не готов.

    Если разберетесь (http://www.buyya.com/superstorage/chap42.pdf), пришлите пожалуйста. Вставлю в таблицу с указанием авторства.

    ОтветитьУдалить
  4. Большое спасибо за аггрегированную информацию и график. Все очень наглядно.
    Единственное но -- полная, не побоюсь этого слова ошибочность ваших выводов насчет какого-либо превосходства iSCSI c Jumbo Frame. Даже из графика видно что самые эффективные протоколы -- FC и SAS, что подтверждается их повсеместным (100%) применением в back end (подключение дисков к контроллеру) всех без исключения дисковых массивов и во front end (подключение хостов к контроллеру) когда нужно высокопроизводительное подключение.

    iSCSI, как видно из графика, весьма перегружен необходимостью процессинга инкапсуляции на различных уровнях. Jumbo frames -- вынужденная мера, внедренная 10 лет назад для повышения производительности при передачи данных по сетям Eghernet, изобретенная тогда, когда не существовало сетевых карт с TCP processing offload capabilities, т.е разбивка потока данных на 1.5кБ пакеты выполнялось связкой ОС/драйвер/ЦП со всеми вытекающими. При наличии TCP offload (а это все 1Гб/с и выше Ethernet NIС чипы на шине PCI-E выпущенные в последние 2-3 года), данный процесс происходит "в железе" и применение jumbo frames не дает никаких плюсов, а только добавляет латентности.
    iSCSI в лучшем случае бывает НЕ ХУЖЕ FC на аналогичной физике только при наличии специализированных iSCSI HBA, которые "в железе" выполняют и Ethernet кадрирование и разбивку потока данных на пакеты и (самое главное) инкапсулируют поток данных по протоколу iSCSI.

    ОтветитьУдалить
  5. дополнение к предыдущему каменту:
    т.е никак невозможно судить об эффективности протокола по величине payload если инкапсуляция данных по протоколу выполняется "в железе" и не ложится в качестве оверхеда на ресурсы хоста

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.