packet per second что это
packets per second
пакетов в секунду
Единица измерения производительности коммуникационного оборудования.
[http://www.morepc.ru/dict/]
Тематики
Смотреть что такое «packets per second» в других словарях:
Throughput — This article is about the use of Throughput in communication networks. For disk drives, see Throughput (disk drive). For business management, see Throughput (business). In communication networks, such as Ethernet or packet radio, throughput or… … Wikipedia
CobraNet — logo Manufacturer Info Manufacturer Cirrus Logic … Wikipedia
NTP server misuse and abuse — covers a number of practices which cause damage or degradation to a Network Time Protocol (NTP) server, ranging from flooding it with traffic (effectively a DDoS attack) or violating the server s access policy or the NTP rules of engagement. One… … Wikipedia
Cobranet — is a combination of software, hardware and network protocols designed to deliver uncompressed, multi channel, low latency digital audio over a standard Ethernet network. Developed in the 1990s, CobraNet is widely regarded as the first… … Wikipedia
New API — (also referred to as NAPI) is an interface to use interrupt mitigation techniques for networking devices in the Linux kernel. Such an approach is intended to reduce the overhead of packet receiving. The idea is to defer incoming message handling… … Wikipedia
Mausezahn — (German for mouse tooth ) is a fast network traffic generator written in C which allows the user to craft nearly every possible and impossible packet. Since version 0.31 Mausezahn is open source in terms of the GPLv2. Herbert Haas, the original… … Wikipedia
PPS — nucl. abbr. Plant Protection System abbr. Packets Per Second abbr. Parallel Processing System abbr. ProduktionsPlanung und Steuerung abbr. Public Packet Switching (network) comp. abbr. Packets Per Second comp. abbr. Power Personal Systems (IBM)… … United dictionary of abbreviations and acronyms
Forwarding plane — Cisco VIP 2 40, from an older generation of routers … Wikipedia
RV-C — is a communications protocol based on the Controller Area Network bus. The protocol is used in recreation vehicles to allow house and chassis components to communicate. RV C is used for control, coordination, and diagnostics, in a multi vendor… … Wikipedia
Weighted fair queuing — (WFQ) is a data packet scheduling technique allowing different scheduling priorities to statistically multiplexed data flows. WFQ is a generalization of fair queuing (FQ). Both in WFQ and FQ, each data flow has a separate FIFO queue. In FQ, with… … Wikipedia
Cisco Nexus switches — The Cisco Nexus Series switches are modular network switches designed for the data center. Cisco Systems introduced the Nexus Series of switches on January 28, 2008. The first chassis in the Nexus 7000 family is a 10 slot chassis with two… … Wikipedia
packets per second
Смотреть что такое «packets per second» в других словарях:
Throughput — This article is about the use of Throughput in communication networks. For disk drives, see Throughput (disk drive). For business management, see Throughput (business). In communication networks, such as Ethernet or packet radio, throughput or… … Wikipedia
CobraNet — logo Manufacturer Info Manufacturer Cirrus Logic … Wikipedia
NTP server misuse and abuse — covers a number of practices which cause damage or degradation to a Network Time Protocol (NTP) server, ranging from flooding it with traffic (effectively a DDoS attack) or violating the server s access policy or the NTP rules of engagement. One… … Wikipedia
Cobranet — is a combination of software, hardware and network protocols designed to deliver uncompressed, multi channel, low latency digital audio over a standard Ethernet network. Developed in the 1990s, CobraNet is widely regarded as the first… … Wikipedia
New API — (also referred to as NAPI) is an interface to use interrupt mitigation techniques for networking devices in the Linux kernel. Such an approach is intended to reduce the overhead of packet receiving. The idea is to defer incoming message handling… … Wikipedia
Mausezahn — (German for mouse tooth ) is a fast network traffic generator written in C which allows the user to craft nearly every possible and impossible packet. Since version 0.31 Mausezahn is open source in terms of the GPLv2. Herbert Haas, the original… … Wikipedia
PPS — nucl. abbr. Plant Protection System abbr. Packets Per Second abbr. Parallel Processing System abbr. ProduktionsPlanung und Steuerung abbr. Public Packet Switching (network) comp. abbr. Packets Per Second comp. abbr. Power Personal Systems (IBM)… … United dictionary of abbreviations and acronyms
Forwarding plane — Cisco VIP 2 40, from an older generation of routers … Wikipedia
RV-C — is a communications protocol based on the Controller Area Network bus. The protocol is used in recreation vehicles to allow house and chassis components to communicate. RV C is used for control, coordination, and diagnostics, in a multi vendor… … Wikipedia
Weighted fair queuing — (WFQ) is a data packet scheduling technique allowing different scheduling priorities to statistically multiplexed data flows. WFQ is a generalization of fair queuing (FQ). Both in WFQ and FQ, each data flow has a separate FIFO queue. In FQ, with… … Wikipedia
Cisco Nexus switches — The Cisco Nexus Series switches are modular network switches designed for the data center. Cisco Systems introduced the Nexus Series of switches on January 28, 2008. The first chassis in the Nexus 7000 family is a 10 slot chassis with two… … Wikipedia
Какую нагрузку на серверы создают сетевые механизмы?
Когда анализируют работу сетевой подсистемы серверов, внимание обычно обращают на такие показатели, как время задержки (latency), пропускная способность системы (throughput), количество пакетов, которое можно обработать за секунду (PPS, Packets Per Second). Эти показатели применяют для того чтобы понять то, под какой максимальной нагрузкой сможет работать исследуемый компьютер. И, хотя эти метрики важны и часто способны многое сказать о системе, они не дают сведений о том, какое воздействие обработка сетевых пакетов оказывает на программы, выполняющиеся на сервере.
Этот материал направлен на исследование нагрузки, создаваемой сетевыми механизмами на серверы. В частности, речь пойдёт о том, сколько процессорного времени решение сетевых задач может «украсть» у различных процессов, выполняющихся в Linux-системах.
Обработка сетевых пакетов в Linux
Linux обрабатывает значительное количество пакетов в контексте любого процесса, выполняемого процессором в момент обработки соответствующего IRQ. Механизм System Accounting назначит используемые для этого такты процессора любому процессу, выполняемому в соответствующий момент. Это будет сделано даже в том случае, если этот процесс не имеет никакого отношения к обработке сетевых пакетов. Например, команда top может указать на то, что процесс, по видимому, использует более 99% ресурсов процессора, но на самом деле 60% процессорного времени будет уходить на обработку пакетов. А это значит, что сам процесс, решая собственные задачи, использует лишь 40% ресурсов CPU.
Один из способов получения вышеописанных показателей заключается в использовании perf :
Вот что может получиться в результате:
В данном случае процессор бездействует (отсюда и появление записей swapper для процесса), IRQ вызывается для очереди Rx на CPU 5, обработка SoftIRQ вызывается дважды, сначала обрабатываются 64 пакета, потом — 27. Следующий IRQ вызывается через 229 мкс и снова запускает цикл.
Эти данные получены на простаивающей системе. Но на процессоре может выполняться любая задача. В таком случае вышеприведённая последовательность событий происходит, прерывая эту задачу и выполняя задачи IRQ/SoftIRQ. При этом System Accounting приписывает прерванному процессу нагрузку, создаваемую на процессор. В результате задачи по обработке сетевых пакетов обычно скрыты от обычных средств мониторинга нагрузки на процессор. Они выполняются в контексте некоего случайным образом выбранного процесса, в контексте «процесса-жертвы». Это приводит нас к некоторым вопросам. Как оценить время, на которое выполнение процесса прерывается ради обработки пакетов? Как сравнить 2 различных сетевых решения для того чтобы понять, какое из них оказывает меньшее влияние на различные задачи, решаемые на компьютере?
При использовании механизмов RSS, RPS, RFS обработка пакетов обычно распределена между ядрами процессора. Поэтому вышеописанная последовательность обработки пакетов имеет отношение к каждому конкретному CPU. По мере увеличения скорости поступления пакетов (полагаю, тут можно говорить о скоростях 100000 пакетов в секунду и выше), каждому CPU приходится обрабатывать тысячи или десятки тысяч пакетов в секунду. Обработка такого количества пакетов неизбежно окажет влияние на другие задачи, выполняемые на сервере.
Рассмотрим один из способов оценки этого влияния.
Отключение распределённой обработки пакетов
Для начала давайте остановим распределённую обработку пакетов, отключив RPS и настроив правила управления потоком, направленные на то, чтобы организовать обработку всех пакетов, имеющих отношение к конкретному MAC-адресу, на единственном, известном нам CPU. В моей системе имеются 2 NIC, агрегированных в конфигурации 802.3ad. Решение сетевых задач возложено на единственную виртуальную машину, выполняемую на компьютере.
RPS на сетевых адаптерах отключается так:
Далее, настраиваем правила управления потоком, направленные на то, чтобы пакеты попадали бы в тестовую виртуальную машину, использующую единственный CPU:
Команда openssl speed
Команда openssl speed практически на 100% является командой пространства пользователя. Если привязать её к некоему CPU, то она, во время выполнения тестов, использует все его доступные ресурсы. Команда работает, устанавливая таймер на заданный интервал (здесь, например, чтобы было легче выполнять расчёты, используется 10 секунд), запуская тест, а затем, при срабатывании таймера, используя times () для того чтобы узнать о том, сколько процессорного времени в реальности досталось программе. С точки зрения syscall это выглядит так:
То есть, оказывается, что между вызовом alarm() и проверкой результатов было сделано очень мало системных вызовов. Если программу не прерывали, или прерывали очень редко, время tms_utime будет совпадать с временем теста (в данном случае это 10 секунд).
Тут видно, что openssl удалось поработать на процессоре 7.49 секунд (178 + 571 в единицах измерения, соответствующих 0.01 с.). Но при этом 5.71 с. этого интервала представлено системным временем. Так как openssl не занят никакими делами в пространстве ядра, это значит, что 5.71 с. — это результат некоей дополнительной нагрузки на систему. То есть — это время, которое у процесса «украли» ради обеспечения нужд системы.
Использование команды openssl speed для выявления нагрузки на систему, создаваемой сетевыми механизмами
Тут можно подумать, что openssl использует примерно 73% ресурсов CPU 5, а ksoftirqd достаются оставшиеся ресурсы. А в реальности в контексте openssl выполняется обработка такого большого количества пакетов, что самой программе на решение её задач достаётся лишь 18-21% процессорного времени.
Если снизить сетевую нагрузку до 1 потока, то возникнет такое ощущение, что openssl достаётся 99% системных ресурсов.
Но в реальности оказывается, что программе, работающей в пользовательском пространстве, достаётся, из ожидаемых 10 секунд, всего примерно 4 секунды:
Обычные средства мониторинга процессов указывают на то, что программа пользуется практически всеми ресурсами процессора, но в реальности оказывается, что 55-80% ресурсов CPU уходит на обработку сетевых пакетов. Пропускная способность системы при этом выглядит великолепно (более 22 Гб/с на 25 Гб/с-линии), но это оказывает колоссальное воздействие на процессы, работающие в этой системе.
Итоги
Здесь мы рассмотрели пример того, как механизмы обработки пакетов «воруют» такты процессора у простого и не особенно важного бенчмарка. Но на реальном сервере процессы, на которые оказывается подобное воздействие, могут быть чем угодно. Это могут быть виртуальные процессоры, потоки эмуляторов, потоки vhost виртуальных машин. Это могут быть разные системные процессы, воздействие на которые способно оказывать различное влияние на производительность этих процессов и всей системы.
А вы учитываете, анализируя свои серверы, влияние на их реальную производительность нагрузки, связанной с выполнением сетевых операций?
forwarding performance и switching capacity
Разберемся с понятиями forwarding performance и switching capacity.
Эти параметры используются для оценки сетевых устройств. Рассмотрим рассчет этих параметров и оценку соответствия сетевого устройства предъявляемым требованиям.
1. forwarding performance
Из-за механизма обнаружения конфликтов Ethernet, размер фрейма данных ограничен когда Ethernet передает фреймы данных. Минимальный кадр данных составляет 64 байта, плюс байты преамбулы 8 байт и межкадровый промежуток 12 байт, итого 84 байта. То есть минимальный кадр данных передаваемый по Ethernet составляет 84 байта.
Возьмем в качестве примера Ethernet интерфейс со скоростью 100 Мбит/с. Каждые восемь битов образуют байт. Поэтому скорость интерфейса Ethernet составляет 100 Мбит/с =12,5 Мбайт / с, То есть интерфейс Ethernet может пересылать 12,5М байт =12500000 байт в секунду. Если предположить, что все кадры данных, передаваемые в худшем случае, являются наименьшими 84 байтами, то кадр данных, передаваемый портом Ethernet 100 Мбит/с в секунду, равен 12500000/84=148809pps (кадр/секунда) =148,8 kpps=0,1488 Mpps.
Например, если существует 24-портовый коммутатор Ethernet 10/100Base-TX, скорость пересылки пакетов (packet forwarding rate) коммутатора составляет 24*0,1488 Mpps=3,5712 Mpps, плюс четыре порта GE 4*1,488 Mpps=5,952 Mpps. Таким образом, общая сумма составляет 3,5712 Mpps +5,952 Mpps =9,5232 Mpps. То есть 24-портовый коммутатор 100 Мбит/с +4 1G Ethernet может реализовать line-rate forwarding только тогда, когда скорость пересылки пакетов всего устройства достигает 9.5232 Mpps.
2. Switching capacity
Switching capacity (backplane bandwidth) коммутатора относится к максимальному объему данных, которые могут быть переданы между процессором интерфейса коммутатора или интерфейсной платой и шиной данных. Switching capacity отражает возможности коммутатора по пересылке данных в битах.
Switching capacity коммутатора = количество портов * скорость работы порта *2 (full-duplex).
Например, switch capacity 24-портового 100М коммутатора равна =24*100*2=4,8 Гбит / с.
Поэтому необходимо оценивать производительность коммутатора на основе forwarding performance и и switch capacity, а не только скоростей интерфейсов и их количества.
24-портовый коммутатор 100 Мбит/с должен иметь forwarding performance 3,5712 Mpps и switch capacity 4,8 Гбит / с. Если эти два параметра не достигают этих значений, производительность коммутатора не соответствует изначальным требованиям.
Качество сетей передачи данных. Программные и аппаратные измерения
Я бы хотел опубликовать цикл статей об измерениях характеристик систем связи и сетей передачи данных. Эта статья вводная и в ней будут затронуты лишь самые основы. В дальнейшем планирую более глубокое рассмотрение в стиле «как это сделано».
Покупая продукт или услугу мы часто оперируем таким понятием как качество. Что же такое качество? Если мы обратимся к словарю Ожегова, то там увидим следующее: «совокупность существенных признаков, свойств, особенностей, отличающих предмет или явление от других и придающих ему определенность». Перенося определение на область сетей связи, приходим к выводу, что нам требуется определить «существенные признаки, свойства и особенности», позволяющие однозначно определить отличие одной линии или сети связи от другой. Перечисление всех признаков и свойств обобщаются понятием «метрика». Когда кто-то говорит о метриках сетей связи, он имеет в виду те характеристики и свойства, которые позволят точно судить о системе связи в целом. Потребность в оценке качества лежит большей частью в экономической области, хотя и техническая её часть не менее интересна. Я же попробую балансировать между ними, чтобы раскрыть все самые интересные аспекты этой области знаний.
Всех заинтересовавшихся прошу под кат.
Мониторинг и диагностика систем связи
Как я писал выше, метрики качества определяют экономическую составляющую владения сетью или системой связи. Т.е. стоимость аренды или сдачи в аренду линии связи напрямую зависит от качества этой самой линии связи. Стоимость, в свою очередь, определяется спросом и предложением на рынке. Дальнейшие закономерности описаны у Адама Смита и развиты Милтоном Фридманом. Даже во времена СССР, когда была плановая экономика, а о «рынке» думали, как о преступлении против власти и народа, существовал институт госприемки, как для военных, так и гражданских целей, призванный обеспечить надлежащее качество. Но вернемся в наше время и попробуем определить эти метрики.
Рассмотрим сеть на основе Ethernet, как самой популярной технологии на данный момент. Не будем рассматривать метрики качества среды передачи данных, поскольку они мало интересуют конечного потребителя (разве что материал самой среды иногда бывает интересен: радио, медь или оптика). Самая первая метрика, которая приходит в голову — пропускная способность (bandwidth), т.е. сколько данных мы можем передать в единицу времени. Вторая, связанная с первой,- пакетная пропускная способность (PPS, Packets Per Second), отражающая сколько фреймов может быть передано в единицу времени. Поскольку сетевое оборудование оперирует фреймами, метрика позволяет оценить, справляется ли оборудование с нагрузкой и соответствует ли его производительность заявленной.
Третья метрика — это показатель потери фреймов (frame loss). Если невозможно восстановить фрейм, либо восстановленный фрейм не соответствует контрольной сумме, то принимающая, либо промежуточная система его отвергнет. Здесь имеется ввиду второй уровень системы OSI. Если рассматривать подробнее, то большинство протоколов не гарантируют доставку пакета получателю, их задача лишь переслать данные в нужном направлении, а те кто гарантирует (например, TCP) могут сильно терять в пропускной способности как раз из-за перепосылок фреймов (retransmit), но все они опираются на L2 фреймы, потерю которых учитывает эта метрика.
Четвертая — задержка (delay, latency),- т.е. через сколько пакет отправленный из точки A оказаться в точке B. Из этой характеристики можно выделить еще две: односторонняя задержка (one-trip) и круговая (round-trip). Фишка в том, что путь от A к B может быть один, а от B к A уже совсем другим. Просто поделить время не получится. А еще задержка время от времени может меняться, или “дрожать”,- такая метрика называется джиттером (jitter). Джиттер показывает вариацию задержки относительно соседних фреймов, т.е. девиацию задержки первого пакета относительно второго, или пятого относительно четвертого, с последующим усреднением в заданный период. Однако если требуется анализ общей картины или интересует изменение задержки в течении всего времени теста, а джиттер уже не отражает точно картину, то используется показатель вариации задержки (delay variation). Пятая метрика — минимальный MTU канала. Многие не придают важности этому параметру, что может оказаться критичным при эксплуатации “тяжелых” приложений, где целесообразно использовать jumbo-фреймы. Шестой, и малоочевидный для многих параметр — берстность — нормированная максимальная битовая скорость. По этой метрике можно судить о качестве оборудования, составляющего сеть или систему передачи данных, позволяет судить о размере буфера оборудования и вычислять условия надежности.
Об измерениях
Поскольку с метриками определились, стоит выбрать метод измерения и инструмент.
Задержка
Известный инструмент, поставляемый в большинстве операционных систем — утилита ping (ICMP Echo-Request). Многие ее используют по нескольку раз на дню для проверки доступности узлов, адресов, и т.п. Предназначена как раз для измерения RTT (Round Trip Time). Отправитель формирует запрос и посылает получателю, получатель формирует ответ и посылает отправителю, отправитель замеряя время между запросом и ответом вычисляет время задержки. Все понятно и просто, изобретать ничего не нужно. Есть некоторые вопросы точности и они рассмотрены в следующем разделе.
Но что, если нам надо измерить задержку только в одном направлении? Здесь все сложнее. Дело в том, что помимо просто оценки задержки пригодится синхронизировать время на узле отправителе и узле-получателе. Для этого придуман протокол PTP (Precision Time Protocol, IEEE 1588). Чем он лучше NTP описывать не буду, т.к. все уже расписано здесь, скажу лишь то, что он позволяет синхронизировать время с точностью до наносекунд. В итоге все сводится к ping-like тестированию: отправитель формирует пакет с временной меткой, пакет идет по сети, доходит до получателя, получатель вычисляет разницу между временем в пакете и своим собственным, если время синхронизировано, то вычисляется корректная задержка, если же нет, то измерение ошибочно.
Если накапливать информацию об измерениях, то на основании исторических данных о задержке можно без труда построить график и вычислить джиттер и вариацию задержки — показатель важный в сетях VoIP и IPTV. Важность его связана, прежде всего, с работой энкодера и декодера. При “плавающей” задержке и адаптивном буфере кодека повышается вероятность не успеть восстановить информацию, появляется “звон” в голосе (VoIP) или “перемешивание” кадра (IPTV).
Потери фреймов
Проводя измерения задержки, если ответный пакет не был получен, то предполагается, что пакет был потерян. Так поступает ping. Вроде тоже все просто, но это только на первый взгляд. Как написано выше, в случае с ping отправитель формирует один пакет и отправляет его, а получатель формирует свой собственный о отправляет его в ответ. Т.е. имеем два пакета. В случае потери какой из них потерялся? Это может быть не важно (хотя тоже сомнительно), если у нас прямой маршрут пакетов соответствует обратному, а если это не так? Если это не так, то очень важно понять в каком плече сети проблема. Например, если пакет дошел до получателя, то прямой путь нормально функционирует, если же нет, то стоит начать с диагностики этого участка, а вот если пакет дошел, но не вернулся, то точно не стоит тратить время на траблшутинг исправного прямого сегмента. Помочь в идентификации могла бы порядковая метка, встраиваемая в тестовый пакет. Если на обоих концах стоят однотипные измерители, то каждый из них в любой момент времени знает количество отправленных и полученных им пакетов. Какие именно из пакетов не дошли до получателя можно получить сравнением списка отправленных и полученных пакетов.
Минимальный MTU
Измерение этой характеристики не то чтобы сложно, скорее оно скучно и рутинно. Для определения минимального размера MTU (Maximum transmission unit) следует лишь запускать тест (тот же ping) с различными значениями размеров кадра и установленным битом DF (Don’t Fragmentate), что приведет к непрохождению пакетов с размером кадра больше допустимого, ввиду запрета фрагментации.
Например, так не проходит:
А так уже проходит:
Не часто используемая метрика с коммерческой точки зрения, но актуальная в некоторых случаях. Опять же, стоит отметить, что при асимметричном пути следования пакетов, возможен различный MTU в разных направлениях.
Пропускная способность
Наверняка многим известен факт, что количество переданной полезной информации в единицу времени зависит от размера фрейма. Связано это с тем, что фрейм содержит довольно много служебной информации — заголовков, размер которых не меняется при изменении размера фрейма, а изменяется поле “полезной” части (payload). Это значит, что несмотря на то, что даже если мы передаем данные на скорости линка, количество полезной информации переданной за тот же период времени может сильно варьироваться. Поэтому несмотря на то, что существуют утилиты для измерения пропускной способности канала (например iperf), часто невозможно получить достоверные данные о пропускной способности сети. Все дело в том, что iperf анализирует данные о трафике на основе подсчета той самой «полезной» части, окруженной заголовками протокола (как правило UDP, но возможен и TCP), следовательно нагрузка на сеть (L1,L2) не соответствует подсчитанной (L4). При использовании аппаратных измерителей скорость генерации трафика устанавливается в величинах L1, т.к. иначе было бы не очевидно для пользователя почему при измерении размера кадра меняется и нагрузка, это не так заметно, при задании ее в %% от пропускной способности, но очень бросается в глаза при указании в единицах скорости (Mbps, Gbps). В результатах теста, как правило, указывается скорость для каждого уровня (L1,L2,L3,L4). Например, так (можно переключать L2, L3 в выводе):
Пропускная способность в кадрах в секнду
Если говорить о сети или системе связи как о комплексе линий связи и активного оборудования, обеспечивающего нормальное функционирование, то эффективность работы такой системы зависит от каждого составляющего ее звена. Линии связи должны обеспечивать работу на заявленных скоростях (линейная скорость), а активное оборудование должно успевать обрабатывать всю поступающую информацию.
У всех производителей оборудования заявляется параметр PPS (packets per second), прямо указывающий сколько пакетов способно «переварить» оборудование. Ранее этот параметр был очень важен, поскольку подавляющее число техники просто не могло обработать огромное количество “мелких” пакетов, сейчас же все больше производители заявляют о wirespeed. Например, если передаются малые пакеты, то времени на обработку тратится, как правило, столько же, сколько и на большие. Поскольку содержимое пакета оборудованию не интересно, но важна информация из заголовков — от кого пришло и кому передать.
Сейчас все большее распространение в коммутирующем оборудовании получают ASIC (application-specific integrated circuit) — специально спроектированные для конкретных целей микросхемы, обладающие очень высокой производительностью, в то время как раньше довольно часто использовались FPGA (field-programmable gate array) — подробнее об их применении можно прочитать у моих коллег здесь и послушать здесь.
Бёрстность
Стоит отметить, что ряд производителей экономит на компонентах и использует малые буферы для пакетов. Например заявлена работа на скорости линка (wirespeed), а по факту происходят потери пакетов, связанные с тем, что буфер порта не может вместить в себя больше данных. Т.е. процессор еще не обработал скопившуюся очередь пакетов, а новые продолжают идти. Часто такое поведение может наблюдаться на различных фильтрах или конвертерах интерфейсов. Например предполагается, что фильтр принимает 1Gbps поток и направляет результаты обработки в 100Mbps интерфейс, если известно, что отфильтрованный трафик заведомо меньше 100Mbps. Но в реальной жизни случается так, что в какой-то момент времени может возникнуть «всплеск» трафика более 100Mbps и в этой ситуации пакеты выстраиваются в очередь. Если величина буфера достаточна, то все они уйдут в сеть без потерь, если же нет, то просто потеряются. Чем больше буфер, тем дольше может быть выдержана избыточная нагрузка.