Давайте сравним методы контроля передачи данных в Fibre Channel и 10GE. Основная из задача – обеспечивать временную остановку передачи данных в случае нехватки входящих буферов портов-получателей. Напомню, что в FC используется механизм контроля счетчиков буферных кредитов. Объединяясь в фабрику, порты коммутаторов обмениваются информацией об общем количестве входных буферов и выставляют соответствующие значения счетчиков буферных кредитов (BB-credits). Отправив пакет, порт декрементирует свой счетчик. Если он обнуляется, отправитель должен остановить передачу. Порт-получатель в свою очередь, обязан явно сообщать о каждой освободившейся ячейке буфера посылкой слова-примитива Receiver Ready (R_RDY), Получив R_RDY, порт получатель инктеменитует значение BB credits.
Такой механизм гарантирует, что порты отправитель и получатель всегда имеют точную информацию о количестве свободных буферов на другом конце линка.
Очень важно отметить, что R_RDY является не FC фреймом (с заголовком, payload, CRC и т. д.), а 4byte (40bit) словом, т. е. объектом минимального размера, допустим для передачи по протоколу Fibre Channel. Соответственно, с точки зрения утилизации каналов накладные расходы контроля передачи данных практически не заметны.
Однако у каждой медали есть обратная сторона. Время между отправкой фрейма и получением сигнала R_RDY сильно зависит от расстояния между портами. Чем больше расстояние, тем дольше отправитель должен ждать инкрементации BB Credits. А это, в случае нехватки кредитов, приводит к задержкам передачи данных и падению загрузки линка.
На приведенном графике значение длины линка, при котором начинается падение утилизации канала, зависит от скорости передачи (Transfer Rate) и количества входных буферов. Увеличение количества доступных входных буферов, приводит к тому, счетчик буферных кредитов обнулится на больших расстояниях. Соответственно, точка перегиба на графике сдвигается вправо.
Давайте теперь рассмотрим протокол Ethernet. Он не имеет примитивов и предусматривает передачу данных в сети только фреймами. Минимальный размер фрейма 64bytes. Если бы в этом протоколе контроль передачи данных был реализован таким же образом, как и в FC, он был бы в 16 раз менее эффективным. Поэтому и был выбран другой метод. Вместо того чтобы постоянно сообщать о количестве свободных буферов, устройства в Ethernet явно сообщают только о событии, когда их не хватает. Таким образом, существенно экономится пропускная способность каналов.
Главным недостатком этого механизма является то, что как и в Fibre Channel, общая эффективность контроля передачи данных заметно падает с увеличением длины линка. Утилизация длинных линков становится низкой.
Для полной загрузки линков на больших расстояниях необходимо либо отключать механизм контроля передачи, либо увеличивать количество входных буферов в коммутаторах, соответствующим образом сдвинув пороговые значения.
На самом деле это выбор без выбора, ведь с отключением Flow Control появится вероятность потери фреймов, что для трафика FCoE совершенно не приемлемо. Поэтому производители увеличивают количество буферных ячеек. На данный момент Cisco повысила максимальную длину линков между своими коммутаторами с 300м. до 3км. (NX-OS 5.0(2)N1.1).
- Nexus 55xx - Nexus 55xx – 3км.
- Nexus 50x0 - Nexus 50x0 - 3 км.
- Nexus 50x0 - Nexus 55xx - 3 км.
- Nexus 55xx - Nexus 2232 – 300м.
- Nexus 50x0 - Nexus 2232 – 300м.
Brocade, вроде, пока ограничивает длину линков 300м.
