Определение реального pps, как?

[@lexey]

Имеем HP 9304m в ядре сети, имеются подозрения в недостаточной пропускной способности девайса. Производитель заявляет

Throughput: 83 million pps (64-byte packets)

Routing/switching capacity: 128 Gbps

c интервалом в 5 секунд собираю (perl-скрипт) сумму OID ifHCInUcastPkts (.1.3.6.1.2.1.31.1.1.1.7) для всех интерфейсов

(32928668411893 - 32831796871237)/5 = 19.3743081 × 10^9

многовато :-)

 

Вывод: я избрал неверный способ определения pps, либо неправильно понимаю этот параметр.

Подскажите куда копать?

[mikevlz]

размер пакетов играет большой рояль. Тяжелее всего пророутить мелкие пакеты(64 байта), именно на них и заявлено 83 миллиона пакетов в секунду. посчитайте, на каком числе пакетов в секунду у вас кончится пропускная способность каналов по схеме максимальной нагрузки. Например, каждую пару портов маршрутизировать только между собой.

он у вас точно не коммутирует ничего? мож там есть пара портов на которых голая коммутация, из-за чего вам все сбивается...

[edo]

размер пакетов играет большой рояль. Тяжелее всего пророутить мелкие пакеты(64 байта), именно на них и заявлено 83 миллиона пакетов в секунду.

то есть на пакетах по килобайту pps будет намного выше? ;)

[desperado]

размер пакетов играет большой рояль. Тяжелее всего пророутить мелкие пакеты(64 байта)

они маленькие такие... стоко времени проходит, пока разглядишь... :)

 

PS

суммируя pps по всем портам, pps как минимум, удваивается, т.к. он учитывается на входящем и исходящем интерфейсах одновременно.

 

PPS

а точно 5 секунд? не 5 минут!? хотя всё равно много...

цифра больше похожа на bps, может повнимательней в МИБы посмотреть?

[@lexey]

mikevlz

Да, Вы правы, один модуль почти полностью коммутируемый (портов 12 из 16 имеющихся), и второй скорее всего тоже. Итого в маршрутизации участвуют около 15 портов.

 

Если честно - я даже не подумал что следует разделять коммутируемые и маршрутизируемые пакеты. :lamer:

 

суммируя pps по всем портам, pps как минимум, удваивается, т.к. он учитывается на входящем и исходящем интерфейсах одновременно.

ifHCInUcastPkts - т.е. только входящие пакеты считаем, другой вопрос - те ли это пакеты которые нужны.

 

цифра больше похожа на bps, может повнимательней в МИБы посмотреть?

посмотрел, нашел столбец

.iso.org.dod.internet.mgmt.mib-2.rmon.statistics.etherStatsTable.etherStatsEntry.etherStatsPkts (.1.3.6.1.2.1.16.1.1.1.5)

Там цифры гораздо более приземленные

(610605905-610586819)/5=3817.2, это на одном из интерфейсов. Если же суммировать показания на всех интерфейсах наблюдаются аномалии на пустых портах - показания меняются не в сторону увеличений, а куда попало.

Вот результаты нескольких последовательных запусков моего скрипта:

46849776469

56651928197

61345137789

71307513405

53949811758

55287944457

59188075307

[desperado]

я не силен именно в этой железке, но я бы попробовал сравнить эти показания с чем-нибудь типа sh int stats на каталистах....

 

чтобы правильно выделить именно L3 на портах, ИМХО, надо очень хорошо знать железку и не факт что это вообще возможно. у самой маршрутизации скорее всего есть свои счетчики не привязанные к портам (или интерфейсам?)

 

и еще... 83Mpps в реальной жизни это однозначно больше 200Gbps, а то и весь 1Tbps. Стоит ли заморачиваться?

Edited November 6, 2007 by desperado

[@lexey]

desperado

В принципе уже стало понятно, что затык явно не в этой железке происходит, к тому же утилизация ЦП не превышает 5 %.

[desperado]

desperado

В принципе уже стало понятно, что затык явно не в этой железке происходит, к тому же утилизация ЦП не превышает 5 %.

не знаю прочих обстоятелств, но, по крайней мере, на одну только загрузку процессора я бы полагаться не стал. 83Mpps не пророутит ни один процессор.

[@lexey]

desperado

Не сочтите за наглость, не могли бы вы привести свою методику проверки такого рода железок (на какие параметры и в каком порядке стоит обратить внимание), теорией то сыт не будешь... а опыта маловато. ;-)

[desperado]

по HP не подскажу.