Производительность libpcap/winpcap
в гугле можно найти
я сколько ни видел - без дропов не получается
по своему опыту - нужен очень большой буфер, сотни мегабайт, чтобы совсем без дропов на сотке, и соответственно не pcap, а какой-нибудь ULOG
я сколько ни видел - без дропов не получается
по своему опыту - нужен очень большой буфер, сотни мегабайт, чтобы совсем без дропов на сотке, и соответственно не pcap, а какой-нибудь ULOG
iptables -j ULOG ?
кстати, можешь намекнуть, по каким ключевым словам нужно искать?
например, по "tcpdump performance" находится:
http://lists.freebsd.org/pipermail/freebsd-questions/2005-Ja... - тут челу советуют буфера в ядре по 8мб сделать. говорят, помогает.
ну и ещё (FreeBSD):
или тут: http://www.mail-archive.com/tcpdump-lists.tcpdump.or...
мне немного непонятно, можно ли софтварно обеспечить снифер на 1гбит или всё-таки обратиться к железке.
на 100мбит народ вроде делает
например, по "tcpdump performance" находится:
http://lists.freebsd.org/pipermail/freebsd-questions/2005-Ja... - тут челу советуют буфера в ядре по 8мб сделать. говорят, помогает.
ну и ещё (FreeBSD):
options DEVICE_POLLING
options HZ=1000
sysctl kern.polling.enable=1
или тут: http://www.mail-archive.com/tcpdump-lists.tcpdump.or...
мне немного непонятно, можно ли софтварно обеспечить снифер на 1гбит или всё-таки обратиться к железке.
на 100мбит народ вроде делает
ну я набрал libpcap performance
там по первой ссылке во всех тестах потери, у FreeBSD меньше, но всё равно дофига
а какие потери у тебя допустимы?
там по первой ссылке во всех тестах потери, у FreeBSD меньше, но всё равно дофига
а какие потери у тебя допустимы?
Device polling к захвату pcap мало отношения имеет. И вообще в 2010 году про него можно забыть.
мне немного непонятно, можно ли софтварно обеспечить снифер на 1гбит или всё-таки обратиться к железке.если только заголовки нужны, то современный комп прожуёт через ULOG (но кажется патч какой-то нужен, чтобы все принятые на физический интерфейс пакеты направлять в ULOG, или может надо в режиме бриджа это делать, не помню)
если полностью гигабитный поток, то наверное смотря что собрался с ним делать, и буфер нужен гигабайтный
нужен весь поток.
что с ним потом делать - исследовать. поиск сигнатур, аномалии и т.п.
смотреть, какие методы можно применить реалтайм на 100мбит и (врядли) на 1гбит
что с ним потом делать - исследовать. поиск сигнатур, аномалии и т.п.
смотреть, какие методы можно применить реалтайм на 100мбит и (врядли) на 1гбит
это я уже видел, да
Device polling к захвату pcap мало отношения имеет. И вообще в 2010 году про него можно забыть.Так что забыть можно polling или pcap?
И почему? :-]
Device polling к захвату pcap мало отношения имеет. И вообще в 2010 году про него можно забыть.А подробнее можно?
Кстати есть какой-нибудь гид по быстрой маршрутизации на FreeBSD?
хм. а какие железяки для этого существуют?
А подробнее можно?Поллинг означает обработку одним тредом. Обработка прерываниями означает что число тредов равно числу сетевых карт, что очень хорошо для SMP. Проблема количества прерываний на современных картах уже не стоит. Во-первых, у хороших карт есть interrupt mitigation, во-вторых, очень себя хорошо показали обработчики прерываний, которые отключают прерывание на время работы обработчика, появляется как-бы адаптивный поллинг. В-третьих, совсем современные карты умеют MSI. Правда я немного отстал от этой темы. Для меня сюрпризом было обнаружить, что при использовании MSI обе сетевых карты обрабатываются одним тредом. Я пока не разобрался почему так и правильно ли это.
А если сетевуха одна (между вланами перекладывается то только 1 ядро нагружаться будет что ли?
Сейчас глянул, у нас после различного тюнинга поллинг в результате выключен всё же. Но когда включали его изначально, то прерывания (в нагрузке процессора) падали.
Сейчас глянул, у нас после различного тюнинга поллинг в результате выключен всё же. Но когда включали его изначально, то прерывания (в нагрузке процессора) падали.
И производительность падала тоже. Самое главное, что и статистика по поводу cpu usage была нечестной 
polling был крут во времена FreeBSD 4 и однопроцессорных машин со стомегабитными сетевухами. Неоднозначное время было во время FreeBSD 5. Сейчас он однозначно не нужен.
polling был крут во времена FreeBSD 4 и однопроцессорных машин со стомегабитными сетевухами. Неоднозначное время было во время FreeBSD 5. Сейчас он однозначно не нужен.И производительность падала тоже.Ну как бы при этом задержки чуть увеличивались, но дропы уменьшились.
Потом мы другие параметры стали крутить и вроде избавились от дропов уже без включенного поллинга. Я вот только не помню что было когда мы его включали.
Ну так я правильно понимаю, что если там 1 сетевуха, то только 1 ядро будет её обрабатывать. Ну т.е. если 2 ядра и прерываний 50%, то жопа?
Почему жопа? Если потерь нет и на машину можно залогиниться, то не жопа.
Почему жопа? Если потерь нет и на машину можно залогиниться, то не жопа.Ну я имею в виду, что надо не на 100% ориентироваться тогда, а на 50% раз такое дело.
API какое-то хреновое, как это интегрировать в event loop?
А хз
я использовал пропатченное ядро + libpcap_pfring
я использовал пропатченное ядро + libpcap_pfring
ну вот например есть такая железяка:
http://www.dianetcom.ru/info/catalog/tester_FlukeNetw/dekode...
стоит 20куе.
есть что-нибудь аналогичное и подешевле?
параметры - 1гбит и умение накопить до 64гбайт
http://www.dianetcom.ru/info/catalog/tester_FlukeNetw/dekode...
стоит 20куе.
есть что-нибудь аналогичное и подешевле?
параметры - 1гбит и умение накопить до 64гбайт
Оставить комментарий
yolki
Можно ткнуть на какие-нибудь ссылки про производительность сниферов вообще и сей штуки в частности?типа "1GHz CPU ought to be enough© для захвата 100мбит без дропов"