Перейти к содержимому
Калькуляторы

x86

Пользователи
  • Публикации

    86
  • Зарегистрирован

  • Посещение

О x86

  • Звание
    Абитуриент

Контакты

  • Сайт
    http://
  • ICQ
    0

Город

  • Город
    Ukraine

Посетители профиля

586 просмотров профиля
  1. Т.е. suricata маркирует трафик? Тогда использование ifb смысла не имеет( или нужно маркировать самому ). Можно пробовать шейпить на исходящем интерфейсе.
  2. ifb на входящем интерфейсе сработает ДО iptables   Хочешь показать, что знаешь умные слова? Ну, покажи где у тебя 7-й уровень используется?
  3. Классифицировать тоже надо через tc - типа tc filter add dev $ifb parent 1: protocol ip prio 1 u32 match u32 0 0 flowid 1:1
  4. Еще раз - что является критерием классификации? Если это интерфейс, то его входящий трафик нужно заворачивать на соответствующий ifb и соответственно на нем шейпить входящий трафик.
  5. Судя по скрипту, классификация делается по интерфейсу. Для шейпинга входящего трафика следует на каждый такой интерфейс завести соответствующий ему ifb, перенаправить на него входящий трафик и соответственно шейпить его на данном ifb.
  6. Простой ответ - никак. Сложный - используйте u32, но это все-равно не даст всех возможностей iptables.
  7. Измерения производились синтетическими тестами iptables на разных ядрах. Что касается оптимизации - используется ipset + бинарный поиск по цепочкам ( с автогенерацией оных ) а иначе для одного из BRAS с iptables -S | wc -l 199918 оно бы просто тормозило.
  8. iptables не работает с ifb. Используйте tc.
  9. Проблема решилась - поставил ядро 4.14.22 и tsc заработал. Попутно ускорил работу iptables в 7(!) раз по сравнению с 4.9 и на 13% по сравнению с 4.1
  10. Внесу свои 5 копеек. У нас каждому интерфейсу назначен IP( он один и тот-же для всех клиентов - и он-же для них default gateway ). А вот DHCP-server у каждого свой, со своим конфигом и слушающий исключительно на этом интерфейсе. Естественно нужно настроить маршрутизацию и если нужно общение между клиентами - то добавить proxy_arp.
  11. Ну да, расскажи мне про 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, как я сейчас и делаю.
  12. Вообще-то культурные незнакомые люди обращаются на вы. Теперь по существу - clocksource он как-бы намекает своим названием откуда берется источник квантов для таймера. Это и подтверждает тот факт, что при источнике refined_jiffies часы идут нормально, а при нестабильном tsc - нет. tsc как раз и позволяет обойтись без генерации прерываний, что делает работу со временем весьма дешевой с точки зрения расходов CPU. C замечанием по HPET согласен, но суть вопроса в том что в available_clocksources его нет, в BIOS включить его возможности нет и соответственно нельзя его использовать для работы со временем. Проблемы-же геймеров на винде с HPET на данном процессоре еще раз говорят о том, что что-то не так с этим процессором. Еще раз повторю - на i5-3570 все было нормально.
  13. Спасибо за совет. Ну, а по теме ничего хорошего. Под нагрузкой одно ядро уперлось в 100%( при этом прерывания были распределены равномерно по ядрам ), а потом пошли и дампы. В общем вернулся на 4.1.44 и полностью исключил использование tc( оно использовалось для QoS и шейпинга входящего трафика ). Пока работает, больше желания его мучить нет. В чем проблема c tsc - непонятно, но скорее всего что-то с самим процессором( в процессе поиска встречал сообщения на немецких форумах, что включенный HPET сильно влияет на производительность Windows в играх ). Мораль сей басни такова - не нужно спешить покупать сильно новое - в нем может быть полно глюков( увы, уровень образования упал не только у нас, но и на западе тоже ).
  14. Вот и первая проблема - отстают часы. Т.е. tsc все-таки не reliable и как с этим бороться пока не понятно.
  15. Поставил 4.13.12 - осталось в available_clocksource только tsc - т.е. проблема решилась. Правда в опциях загрузки оставил tsc=reliable clocksource=tsc В BIOS выключил Intel Speed Shift - иначе выдавало дампы. Попутно пришлось собрать iproute2-4.13.0 c мелкой правкой исходников( иначе не собиралось ) - со старым тоже были дампы. Теперь остается посмотреть на стабильность работы нового ядра.