Как увеличить производительность ядра в задачах типа непрерывного захвата пакетов.

Однако Win2K рулит ...

вывод - Win2k для настоящих какеров!

Не вижу повода зубоскалить. Это же просто катастрофа! Так часто тут хаемая БСД, которую обсирают за неподдержку "энтерпрайза", справляется с большой сетевой нагрузкой НА ПОРЯДКИ лучше Линукса!!! Если тут есть кернельные хакеры, то я бы советовал им обратить внимание на выявленный автором недостаток ядра и срочно(!) реализовать предложенную им идею в ядре. Конечно, здорово бы было, если все изменения можно было бы локализовать ТОЛЬКО в коде ядра, без модификации библиотек.

недосаток один - качество работы линуха с процами от виа

Дык кто бы сомневался, у них стек TCP/IP из BSD

хех а в итоге линуха всех делает ... конечно надо ручками поработать но все же ...

А просто остальные статью до конца не дочитали и дальше первой таблицы не продвинулись:) ...И даже не заметили что 2k там дальше не рассматриваеться как та которая не в курсе про поллинг вообще...

неправда. дочитали до конца. просто никто нужным не счел об этом сообщать

libpcap это не показатель. Ядро должно передавать пакеты user-space'у асинхронно, не задерживаясь, для чего и предназначен ULOG target в netfilter - выбранные (или все) пакеты передаются через netlink в userspace.

>Дык кто бы сомневался, у них стек TCP/IP из BSD

Ну и почему тогда у BSD хуже результат?

Блин, ну неужели на ЛОРе могут только пиписьками меряться??? Какая разница, в чем причина того, что Windows лучше на не самом совершенном из доступных для БСД способов? Факт ведь в том, что Линукс без офигительно огромного напильника, без модификиции как кода драйвера сетевой платы так и библиотеки захвата показывает УЖАСАЮЩЕ низкие результаты! Даже на супер-пупер новом ядре 2.6! На стандартном юзерспейсном libcap и 2.4.х Линукс хуже >100 раз (чем БСД) (таблица 1)! А на 2.6 даже с ядерным модулем почти в 10 (таблица 3)!
Еще раз для тупых - ЭТО ПРОСТО КАТАСТРОФА! Такое ядро нельзя подпускать к серьезным сетевым сервисам! Даже 2.6! Нужно срочно что-то делать!

Ну че ты так переживаешь?

Поставь BSD.

> Еще раз для тупых - ЭТО ПРОСТО КАТАСТРОФА!
> Такое ядро нельзя подпускать к серьезным сетевым сервисам!
Неприятно.
Но ты не преувеличивай, работа серьезных сетевых сервисов отличается от работы сниффера. Это другой таск, не совсем показательный.
> Даже 2.6! Нужно срочно что-то делать!
Для начала сравнить работу на нормальных сетевых сервисах.

Вообще-то если дочитать до конца, Linux выигрываетс кольцевым MMap буфером у Win и BSD и это уже реализовано для него, а для BSD автор только собирается начать ;)..

Да как оно, не переживать-то? Вот мы кричим, что HURD - это типа академическая ОС. Ага, но думать-то при проектировании кто будет? Или у нас руки только под печать заточены? Блин, пришел перец, не титан даже, а так, аспирант, ну пусть даже и талантливый (поскольку не знаком лично, не могу обижать человека). И просто поставил обычный эксперимент. Нашел проблему и решил ее! Да так, что все просто утерлсь! Это же дыра в проекте, что можно было вот так, просто придти и поднять с пола такую задачу! А сколько, получается их лежит, слегка прикрытые пылью?
Мораль из всей истории: думать, ребята, надо перед тем, как код писать. И не кричать: "А у нас такая рульная ОС, что всех заруливает".

> Вообще-то если дочитать до конца, Linux выигрываетс кольцевым MMap буфером

При условии использования этого самого буфера (патч ядра. вопрос, насколько стабильный), и переписывания юзерленда. У BSD таких проблем нет. Да и начинается отставание уже на гигабитных карточках. А по загрузке процессора - вообще в линуксе засада с этим буффером.

Кстати, автор не тестировал еще и zero-copy на FreeBSD - вот это, плюс DEVICE_POLLING, реально дает выигрыш на гигабитных каналах. Еще автор не указал значение HZ, поскольку разница между дефолтным HZ=100 и HZ=5000 очень заметна. Да и bpf во фре есть... Короче, можно еще тюнить и тюнить...

И самим тестированием никто америку не открыл - у меня на 100Мб бекбоне так IDS через tap с каталиста работает (на два гигабитных порта весь траффик гонится).

кто знает, если я под явой собираю udp-пакеты, где наиболее узкое место в смысле статьи?

чего переживать то, во первых одна статья не факт, во вторых сами подумайте

>> Какая разница, в чем причина того, что Windows лучше на не самом совершенном из доступных для БСД способов?
>> Еще раз для тупых - ЭТО ПРОСТО КАТАСТРОФА! Такое ядро нельзя подпускать к серьезным сетевым сервисам! Даже 2.6! Нужно срочно что-то делать!


Батенька, прежде, чем подымать гвалт, советую разобраться с сутью проблемы и откуда она проистекает.

Задачи захвата и анализа пакетов в корне отличаются от работы сетевых сервисов.

Что необходимо для нормальной работы сетевого сервиса?
Надо принять пакеты на интерфейсе и максимально быстро и эффективно ОТСЕЧЬ те, которые НЕ ПРЕДНАЗНАЧЕНЫ для обработки на данной системе.

Что необходимо для захвата и анализа пакетов?
Надо принять ВСЕ пакеты, не зависимо от их назначения, и с минимальными потерями передать их в систему анализа.

С точки зрения сетевых сервисов для работы стека НОРМАЛЬНЫМ и ЕСТЕСТВЕННЫМ является поведение, когда можно (а иногда и нужно) "потерять" пакеты, которые не предназначены для обработки на этой системе. Чем раньше (с точки зрения стека) и качественнее "теряются" такие пакеты, тем более эффективно работает стек, меньше расходуется системных ресурсов и т.п.

Большинство стеков универсальных устройств и ОС оптимизируется именно для этих задач.

От чего при таком подходе зависит количество "непотерянных" пакетов при захвате всего трафика (если не предпринимать специальных мер для обеспечения режима захвата пакетов)?
Прежде всего от скорости обработки пакетов стеком (задержка при передаче на след. уровень), включая задачи фильтрации "не своих" пакетов, временных параметров опроса входных буферов, размера этих буферов и политики вытеснения в буфере.

Если стек обрабатывает пакеты медленнее, чем может опрашивать приложение, осуществляющее захват, то необходимы буфера большого размера, и потерь будет относительно мало. Предположительно, именно это и происходит в Windows. Расплатой за это служит увеличенный расход памяти + издержки на управление + повышенная задержка по передаче пакетов приложению, что в некоторых случаях может привести к проблемам сетевых служб при плотном входном потоке. Такой дизайн применяется, что бы большими буферами и мягкими политиками компенсировать медленный "проход" по стеку.

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

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

Человек же предложил некую конструкцию (так, кстати, работает очень много сетевого железа), при которой не падает эффективность стека, но и не теряются пакеты. Расплатой за это является увеличенный расход памяти (не более 100-200К на интерфейс), но за счет ее статической структуры практически отсутствуют побочные эффекты. Второй платой за это являются дополнительные требования к написанию драйверов, впрочем достаточно простые.

Т.о. в первой табличке с точки зрения обычной работы ОС нет какого-либо криминала и какой-либо информации, на основании которой можно делать далекоидущие выводы.

Родненький Вы мой! Я ведь не говорю, что Linux после этого теста стал непригоден к использованию. Вы сами отметили то, что есть самое важное в этом материале:
> Человек же предложил некую конструкцию (так, кстати, работает очень
> много сетевого железа), при которой не падает эффективность стека, но
> и не теряются пакеты. Расплатой за это является увеличенный расход
> памяти (не более 100-200К на интерфейс), но за счет ее статической
> структуры практически отсутствуют побочные эффекты. Второй платой за
> это являются дополнительные требования к написанию драйверов, впрочем
> достаточно простые.

Именно это мне и кажется самым неприятным (не катастрофа, конечно, это я перегнул). То, что такая простая и эффективная технология осталась фактически за бортом. А ведь многие использования Linux как раз и требуют эффективного захвата пакетов, иначе что мы сможем обработать?
Если совсем коротко, то захват пакетов НЕ ДОЛЖЕН быть узким местом системы.

>Мораль из всей истории: думать, ребята, надо перед тем, как код писать. И не кричать: "А у нас такая рульная ОС, что всех заруливает".

Мораль другая. GPL -- rulezzz foreva.

Именно потому что "какой-то аспирант" может взять и поднять с пола такую штуку.

>То, что такая простая и эффективная технология осталась фактически за бортом

Странные люди. За каким бортом? Открытые исходники для чего: появилась задача - тут же появилось решение

Братва, ну не нужно оправдываться. Я и так прекрасно понимаю, что легко исправить, открытые исходники и т.п. и т.п.

Вопрос вот в чем: если все это так хорошо,как описывалось, то когда это решение(или его потомки) попадут в ядро/библиотеку?

> Ну и почему тогда у BSD хуже результат?

Это риторический вопрос :-)

>Вопрос вот в чем: если все это так хорошо,как описывалось, то когда это решение(или его потомки) попадут в ядро/библиотеку?

Тогда, когда это будет востребованно. Если подобная технология нужна одному-двум на пару миллионов пользователей - то эти один-два хакера разберутся в проблеме, напишут изменения/дополнения/патчи/драйверы и будет им "щастье". Либо выкачают из и-нета необходимый софт. А если эта технология станет распространенной, то в ядро включат в самое ближайшее время.

> такая простая и эффективная технология осталась фактически за бортом pcap? pcap sucks. It has not very good and BSDish design. It is also known to loss packets on any system if CPU load exceeds some margin. > захват пакетов НЕ ДОЛЖЕН быть узким местом системы. Yes, sure. And this is what Linux kernel iptable is for. Use libipq and have fun. E.g.: NetAMS. cf. pcap and ipq ifdefs.

> такая простая и эффективная технология осталась фактически за бортом
pcap? pcap sucks. It has not very good and BSDish design. It is also known to loss packets on any system if CPU load exceeds some margin.
> захват пакетов НЕ ДОЛЖЕН быть узким местом системы.
Yes, sure. And this is what Linux kernel iptable is for. Use libipq and have fun. E.g.: NetAMS. cf. pcap and ipq ifdefs.