x86

Вот по-поводу tickless и HTB

Посмотрите https://www.atirra.com/

1. Нужно сравнить perf top на старом сервере и на новом. 2. Используется-ли iptables в процессе работы? Если да, то их серьезно поломали в плане скорости в ядрах 4.4 и 4.9, исправили в 4.14 3. Поскольку используется quagga, следует заметить что в ядрах с 3.6 выпилили ip route cache - возможно, в некоторых конфигурациях, это сказывается на производительности.

Заводите аналоговый сигнал на что-то типа GoTView PCI DVD, получаете на выходе поток, его отправляете на головную станцию, и там уже подмешиваете в оптический сигнал, который идет к вам.

Т.е. suricata маркирует трафик? Тогда использование ifb смысла не имеет( или нужно маркировать самому ). Можно пробовать шейпить на исходящем интерфейсе.

ifb на входящем интерфейсе сработает ДО iptables   Хочешь показать, что знаешь умные слова? Ну, покажи где у тебя 7-й уровень используется?

Классифицировать тоже надо через tc - типа tc filter add dev $ifb parent 1: protocol ip prio 1 u32 match u32 0 0 flowid 1:1

Еще раз - что является критерием классификации? Если это интерфейс, то его входящий трафик нужно заворачивать на соответствующий ifb и соответственно на нем шейпить входящий трафик.

Судя по скрипту, классификация делается по интерфейсу. Для шейпинга входящего трафика следует на каждый такой интерфейс завести соответствующий ему ifb, перенаправить на него входящий трафик и соответственно шейпить его на данном ifb.

Простой ответ - никак. Сложный - используйте u32, но это все-равно не даст всех возможностей iptables.

Измерения производились синтетическими тестами iptables на разных ядрах. Что касается оптимизации - используется ipset + бинарный поиск по цепочкам ( с автогенерацией оных ) а иначе для одного из BRAS с iptables -S | wc -l 199918 оно бы просто тормозило.

iptables не работает с ifb. Используйте tc.

Проблема решилась - поставил ядро 4.14.22 и tsc заработал. Попутно ускорил работу iptables в 7(!) раз по сравнению с 4.9 и на 13% по сравнению с 4.1

Внесу свои 5 копеек. У нас каждому интерфейсу назначен IP( он один и тот-же для всех клиентов - и он-же для них default gateway ). А вот DHCP-server у каждого свой, со своим конфигом и слушающий исключительно на этом интерфейсе. Естественно нужно настроить маршрутизацию и если нужно общение между клиентами - то добавить proxy_arp.

Ну да, расскажи мне про RTC как источник времени и особенно про его точность. Еще раз, для тех кто в танке - объясни почему при clocksource refined-jiffies время не сбивается, а при нестабильном tsc - серъезно запаздывает. Последнее обновление microcode на сайте Intel'a 0x2000022 от 07.07.17 cpuinfo у меня сейчас показывает версию 0x200002b ( и я так понимаю оно берет его из BIOS ). Ты путаешь понятие таймера и времени. Бесспорно, таймер вещь совершенно необходимая и лучшее из всего, что на данный момент есть - это HPET( но кстати у меня он тоже недоступен почему-то ) А вот для работы со временем лучше всего обходится без прерываний вообще и tsc здесь совершенно незаменим так как у него минимальные накладные расходы. Для задач Traffic Control нам как-раз нужно измерение интервала времени между двумя событиями. Проверяется просто - берется более ранний процессор, и если там все работает, значит проблема в железе. Ryzen и Broadwell X - это новые архитектуры, и вполне возможно, что внутри содержат много недоработок. Вот ознакомился с Errata на Xeon - 92 проблемы со статусом No Fix за период с 07.2016 по 09.2017 Можно использовать для других целей. Или без Traffic Control, как я сейчас и делаю.

Вообще-то культурные незнакомые люди обращаются на вы. Теперь по существу - clocksource он как-бы намекает своим названием откуда берется источник квантов для таймера. Это и подтверждает тот факт, что при источнике refined_jiffies часы идут нормально, а при нестабильном tsc - нет. tsc как раз и позволяет обойтись без генерации прерываний, что делает работу со временем весьма дешевой с точки зрения расходов CPU. C замечанием по HPET согласен, но суть вопроса в том что в available_clocksources его нет, в BIOS включить его возможности нет и соответственно нельзя его использовать для работы со временем. Проблемы-же геймеров на винде с HPET на данном процессоре еще раз говорят о том, что что-то не так с этим процессором. Еще раз повторю - на i5-3570 все было нормально.

Спасибо за совет. Ну, а по теме ничего хорошего. Под нагрузкой одно ядро уперлось в 100%( при этом прерывания были распределены равномерно по ядрам ), а потом пошли и дампы. В общем вернулся на 4.1.44 и полностью исключил использование tc( оно использовалось для QoS и шейпинга входящего трафика ). Пока работает, больше желания его мучить нет. В чем проблема c tsc - непонятно, но скорее всего что-то с самим процессором( в процессе поиска встречал сообщения на немецких форумах, что включенный HPET сильно влияет на производительность Windows в играх ). Мораль сей басни такова - не нужно спешить покупать сильно новое - в нем может быть полно глюков( увы, уровень образования упал не только у нас, но и на западе тоже ).

Вот и первая проблема - отстают часы. Т.е. tsc все-таки не reliable и как с этим бороться пока не понятно.

Поставил 4.13.12 - осталось в available_clocksource только tsc - т.е. проблема решилась. Правда в опциях загрузки оставил tsc=reliable clocksource=tsc В BIOS выключил Intel Speed Shift - иначе выдавало дампы. Попутно пришлось собрать iproute2-4.13.0 c мелкой правкой исходников( иначе не собиралось ) - со старым тоже были дампы. Теперь остается посмотреть на стабильность работы нового ядра.

Да, придется пробовать свежее ядро. Но там могут быть свои проблемы - вот 4.4 дико тормозило при загрузке правил iptables/шейперов, в 4.9 периодически пропадали локальные сессии по TCP.

Да, я тоже склоняюсь к мнению, что это аппаратная проблема. Microcode, насколько мне известно обновляется на уровне BIOS и его я обновил до версии F4 от 20.09.17, но проблему это не решило.

Прошу помощи у знатоков. Обновили сервер на i7-7820X на Gigabyte X299 UD4. Ядро 4.1.44 нормально работало на прежнем i5-3570. Теперь при старте в dmesg получаю: [ 0.000000] tsc: Fast TSC calibration failed [ 0.000000] tsc: Unable to calibrate against PIT [ 0.000000] tsc: No reference (HPET/PMTIMER) available [ 0.000000] tsc: Marking TSC unstable due to could not calculate TSC khz Соответственно в cat /sys/devices/system/clocksource/clocksource0/available_clocksource refined-jiffies jiffies Даже hpet не включает ибо [ 0.241000] pci 0000:00:1f.0: RCBA disabled; cannot force enable HPET BIOS последней версии ( F4 ), Hyper-Threading и всевозможное энергосбережение в Setup выключено . В оциях загрузки ядра добавил intel_pstate=disable tsc=reliable clocksource=tsc processor.max_cstate=1 intel_idle.max_cstate=0 - толку никакого.

Как оно мысли совпадают - Прохожий сказал про комиссара, а я как раз про него написать собрался :) Идея комиссара простая - сбор информации о жизнедеятельности каждого подразделения непосредственно на месте(!) и последующая первичная(!) аналитика, НО больше никакой реальной власти. Таким образом недельку комиссар живет в одном отделе, потом в другом и так пока не обойдет все - при этом он слушает, спрашивает, снова слушает, наблюдает за работой, даже у клиента. Важно - людям надо объяснить - никаких оргвыводов по обнаруженным косякам НЕ БУДЕТ(!), наоборот, предложения по улучшению приветствуются и вознаграждаются. Потом с первичной аналитикой комиссар идет к руководителю и его ближайшему окружению для последующего мозгового штурма выявленных проблем и путей их решения. При этом по обнаруженным косякам нужно предупредить руководителей отделов, что если именно такое-же повториться, то они будут вздрючены по-первое число. Кроме того, у руководителей отделов и других высших управленцев должна быть возможность обращаться к комиссару при возникновении проблем на уровне между отделов или особо сложных проблем, а комиссар должен регулярно встречался с директором, докладывая о текущей ситуации для принятия тех или иных решений. Еще подкину идею - каждый работник предприятия должен иметь возможность обратиться( пускай и анонимно ) по поводу любой проблемы на предприятии ( эдакий почтовый ящик ). Директор должен это бегло просматривать и раздавать указания кому разобраться и доложить. Более того, если обращение было не анонимным и принесло экономический эффект для предприятия - то инициатора надо публично поощрить и наградить. И еще - по поводу развития в нечто новое. НЕ стоит пытаться людей загруженных текущей работой заставлять/поощрять куда-то развиваться - они ведь делают свое дело и наверное стараются его делать хорошо, а заниматься чем-то еще у них нет ни сил ни времени. А для новых направлений - нужны новые люди( или старые - но без текущих обязанностей ).

Есть ли практический опыт проверки такого предположения? Гигабит симметричного трафика? В реальной нагрузке было 850/150 Mbit при 120 kpps - 2-а ядра из 4-х загружены примерно на 30% При этом используется NAT, shaper, QoS, много экранов правил iptables, ipcad, DNS-сервер + кучка самописных демонов. Несколько лет назад тестировал разогнанный Celeron 430 на 2-х Realtek-ах PCI-Express - на чистом роутинге получил в сумме 686k pps, ну а на максимальных пакетах - без перегрузки роутера 964/957 Mbit. В обоих случаях речь идет о симметричном траффике.

Slackware - наше все :) А вообще дистрибутивы отличаются менеджерами пакетов да скриптами инициализации - отсюда и выбирайте, что ближе. IMHO, железо чистый роутинг должно потянуть - по примерному расчету 1 ядро - 1 гигабит трафика.