Контроль передачи данных в конвергентных сетях. часть 2

Часть 1 здесь
Использовалась статья Cisco

Итак, мы остановились на том, что чем длиннее кабель, тем раньше должна быть передана пауза. Насколько раньше? Для того чтобы не потерять ни одного фрейма данных, “запаса” свободных буферов должно быть достаточно для сохранения всех фреймов которые будут посланы, пока PAUSE дойдет до отправителя и будет им обработана. Пороговое значение количества свободных буферов, при котором высылается пауза должно быть установлено, учитывая следующие факторы:

• Обмен данными возможен в обоих направлениях. Если порт получатель уже начал передавать какой-то пакет, то прерывать эту передачу для того, чтобы послать PAUSE не разумно. Поэтому будет задержка, достаточная для передачи данных объемом MTU-1bit (рассматриваем самый худший случай). Напоминаю, MTU = Maximum Transmission Unit. Так как MTU для различных CoS может быть разным, нужно брать максимальный.

• Скорость распространения электромагнитного сигнала в меди составляет около 70% от скорости в вакууме. В оптическом кабеле она еще чуть меньше и составляет 65%. Поэтому каждые 100м. кабеля добавляют 476нс. (медь) или 513нс. (оптика) задержки. За время пока PAUSE путешествует по 100м. кабелю, порт-отправитель на 10Gbps передаст 641byte (берем худший случай более медленной оптики). А так как на момент отправки PAUSE по кабелю к получателю уже передавались какие-то данные, этот объем надо удвоить. Округленно получаем 1300bytes на каждые 100м.

• При получении PAUSE порт получатель должен ее обработать и подать команду на остановку трафика. Протокол PFC предписывает это сделать не более чем за 60 квантов времени (кванты обсуждались в предыдущем посте), что эквивалентно передаче 512bits * 60 квантов = 3840bytes.

• После того, как послана команда на остановку трафика, необходимо все-таки дождаться, пока пакет, который уже начался передаваться, полностью уйдет. Соответственно, опять будет задержка, достаточная для передачи данных объемом MTU-1bit (самый плохой случай). причем здесь должно приниматься во внимание MTU только CoS FCoE.

Суммарно, мы получаем постоянную задержку, эквивалентную 9216bytes (максимальное MTU Ethernet) + 3840bytes + 2240bytes (максимальное MTU FCoE) = 15296bytes, а также задержку, 1300bytes на каждые 100м. кабеля. На максимально допустимой в данный момент длине кабеля 300м. мы получим задержку эквивалентную 15296bytes + 3 * 1300bytes = 19196bytes.

Есть еще один момент, о котором не стоит забывать. Он заключается в том, что буферная память организована не как единое непрерывное хранилище данных, а виде отдельных ячеек или блоков. Размеры этих ячеек зависят от конкретной модели устройств. Так, Cisco в своих коммутаторах Nexus 5000 и экстендерах Nexus 2000 они составляют 160bytes и 80bytes соответственно.

Ethernet фрейм минимального размера 64bytes в буферах Nexus 5000 будет занимать всего 40% объема ячейки. А так как неиспользованная память в ячейках применяться для хранения других данных уже не может, оставшиеся 96bytes просто пропадают.

Итак, в самом худшем случае фреймов 64bytes мы имеем 60% накладные расходы на использованный объем буферной памяти. Наши 19196bytes поместятся в 300 пакетов размером 64bytes. Это, в свою очередь, приведет к использованию 300 * 160bytes = 48000bytes буферной памяти (около 1/10 от общего объема памяти в Nexus 5000).

Итак, в рассмотренном конкретном примере, пороговое значение, при котором высылается PAUSE на передачу FCoE, равно 300 буферных ячеек. Использование функциональности lossless Ethernet с другими сетевыми протоколами, например iSCSI, за счет снижения количества ретрансмитов данных дает дополнительные преимущества производительности. Однако, стоит учитывать, что в этом случае пороговое значение паузы будет еще выше. В случае Cisco Nexus 5000 оно будет равно 409 буферных ячеек.

В данный момент Cisco NX-OS поддерживает PFC только до 3 CoS:

• 1x FCoE (mini Jumbo MTU 2240bytes)
• 1x сетевой трафик с jumbo MTU 9216bytes
• 1x сетевой трафик со стандартным MTU 1500bytes

Часть 3 здесь...