Любой пром коммутатор в пределах своей пропускной способности обрабатывает кадры Ethernet с задержками несравнимо меньшими чем фильтрация дребезга на дискретном входе. Зачем отдельная очередь?

Обоснование цены, все ж понимают 😜

Ну так я не в поддержку серверов. Я к тому, что не понятно какие именно сервера @Nixmak предлагает менять раз в 5 лет...

Это был риторический вопрос, чтобы  не сложилось иллюзий...

на случай, если пределы пропускной способности будут превышены, я думаю

При каких условиях превышены?

из-за сбоев ПО сетевого оборудования и рассылки паразитного трафика, например

Не совсем понимаю — речь идёт о какой-то гипотетической угрозе или реальном прецеденте?

у меня на столе нет сети процесса или станции. по сети станции встречался с таким на АЭС

Это типа QoS только звучит круче.

типа да. и за это дополнительные деньги платят

Вставлю свои 5 копеек. Никогда не встречались с некорректной работой физических интерфейсов? Например, в терминале МПРЗ одного известного производителя самопроизвольно формируется уведомление типа Topology Change Notification (STP). Терминал находится в кольцевой ЛВС. Хуже того, таких терминалов несколько. По итогу пока топология установится - сессии TCP померли уже. Потом все поднимается, а это вычитка модели и тонна трафика. И опять падает, потому что какой-то терминал опять решил топологию поменять.

В продолжение к изложенному: Еще один интересный косяк - бред интерфейса. Никогда не видели, как на коммутаторах таблицы CAM переполняются из-за того что интерфейс устройства шлет с разными MAC-адресами пакеты? Я - видел.

Еще интересный способ перегрузить коммутатор - настроить асимметричные VLAN неправильно и получить передачу данных в одну сторону в рамках VLAN, а обратно - в нативе. По итогу из коммутатора концентратор прикольный получается. Мало того, все устройства в ЛВС получают ARP ответы, которые воспринимают как GARP и соответственно забивают свои таблицы ненужными адресами.

Вообщем, если про условия - тысячи их! (С) Лурк

Все приведённые примеры — это примеры ненормальной работы чего-либо, которые, к тому же выявляются по косвенным признакам. Их надо устранять путём исправления проекта / устройств / конфигурации. С таким же успехом терминал просто может внезапно перестать принимать GOOSE-сообщения ( мы с таким тоже сталкивались). Но на все эти случаи не напасёшься доп. функционала.

В условиях, в частности, работы РЗА в режиме «дежурства» достаточно просто планомерно выявлять и устранять эти проблемы, так как они не будут приводить мгновенно к отказу функционирования. Усложнение же оборудования, направленное на решение этих проблем будет вести только к появлению ещё большего количества проблем.

Не говоря уже о цене.

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

Вы забываете, что по вычислительной мощности средний сервер эквивалентен нескольким десяткам средних терминалов. Т.о. удельная стоимость единицы производительности у серверов существенно ниже. Кроме того серверы того же hp внедряются миллионами штук ежегодно, что позитивно сказывается на стоимости и отработанности решения. Ни одной серии Мурза такого не снилось.