>> Абсолютно не верно. Вы пробовали Атлон на 10Гбитных картах. Его с головой
>> хвататет. В тех ссылках что я скидывал об этом написано.
> а вы сами пробовали? ;) у него маленький кэш и относительно невысокая
> производительность.
> и какой смысл в такой несбалансированной системе, где сетевая карточка стоит несколько
> сотен баксов и процессор - сотню?

Так не надо переводить сбалансированнсоть системы в баксовый вклад каждого компонента. Смотрите, если для определенных задачь требуется стобаксовая сетевая, хватает 60 баксового процессора и 10 баксвовой видеокарты, то вы считаете систему не сбалансированной. Система выполняет свои фугкции полностью и ни один компонент не является узким местов - вот принцип сбалансированности. Ваш подход к сбалансированности системе чисто юзерский).

> чуть пригрузите шейпером/натом и железка "умрёт".
>>  И после этого вы будете говорить, что понимаете работу PF? Слабо
>> в это вериться :-)
> уважаемый Артём! Если вы с чем-то не согласны, попробуйте хоть как-то аргументировать
> свою точку зрения. Если вы считаете, что время state lookup в
> pf не зависит от числа стейтов - подтвердите это чем-то(например, рассказав
> про используемую структуру данных и время поиска/вставки/удаления элемента в ней).

Зависит, но не так критично как вы думаете. Чисто из практики. По умолчанию кол-во стейтов ограничено 10000. Когда число стейтов будет равно 10000 ПФ будет нормально работать и не "умрет" как вы пишите. Но просто не будет создавать новые подключения. Что бы избежать подобных ситуаций есть адаптивный механизм регулировки  кол-ва стейтов. Я это использую на внешнев интерфейсе. Видел системы, построеные не мной, где кол-во было ограничено 200к и проблем с нагрузкой не было.

> afaik, в pf state table в openbsd защищена giant lock'ом(хотя, во freebsd
> это несколько  иначе).

Во freebsd скоро совсем  будет иначе. Имею ввиду PF SMP friendly :-)