Тестирование аллокатора памяти FreeBSD

>Скоро :)) И признаки тому уже есть

Я это "скоро" слышу последние лет 15 ;)

>Разве Линус уже перешел на ГПЛv3?

Не понял мысли. Оно-то как связано ?

http://nexus.org.ua/weblog/message/406/
Волшебство netgraph. Модуль ng_netflow и графическая структура трафика на Netflow Analyzer 4.

12:26, 20 ферваля 2006 ( Administration FreeBSD )

Что же представляет собой netgraph?

Если в двух словах, то netgraph это как высокоуровневый Basic для сетевых сервисов по сравнению с машинным кодом. Идеология netgraph позволяет путем создания визуальных графов из "кубиков" протоколов, портов и сервисов как бы строить взаимодействие сетевых компонентов простым созданием связей между "кубиками".

Надо отметить что netgraph работает на уровне ядра, и, как сказали бы англоязычные братья, this is god damn fast.Надо сказать что к осознанию netgraph я подходил несколько раз. И каждый раз найденная в небольшом количестве рускоязычная документация не раскрывала темы, да и в общем не давала полного понимания принципов работы.

Из моего примера вы почерпнете технику создания связей для узлов (nodes) сетевых протоколов и интерфейсов и научитесь при помощи модуля ng_netflow отправлять статистику сетевых соединений в формате Cisco на обрабатывающий хост, в моем случае это Netflow Analyzer 4 от AdventNet Inc.

Что нам потребуется для реализации статистики по структуре трафика:
1. FreeBSD роутер (192.168.0.1), с которого будем собирать статистику, ядро скомпилировано с поддержкой netgraph.
2. Windows хост (192.168.0.12), на который будут приходить пакеты в формате Cisco netflow.
3. установленный модуль ng_netflow (/usr/ports/net/ng_netflow)
4. установленный Netflow Analyzer 4 на windows хост, прослушивающий UDP пакеты на порту 9996
....

RMS издал фетву о запрещении GPLv2/LGPLv2 ? O_o

>>> netgraph
>>А вот этой вкусняшки в лупиксе никогда не будет :)

>скажите, а что в нём такого? ну да, можно как из кубиков что-то собирать...

>А зачем, кроме как трафик считать?

Цитата: http://nexus.org.ua/weblog/message/406/
"Следует отметить, что netgraph исключительно мощная система, что доказывает очень известный и популярный продукт MPD VPN для PPTP, который полностью работает на netgraph"
Ведь использовать netgraph можно не только для подсчета трафика ;)

>"Следует отметить, что netgraph исключительно мощная система, что >доказывает очень известный и популярный продукт MPD VPN для PPTP, >который полностью работает на netgraph" >Ведь использовать netgraph можно не только для подсчета трафика ;) >iZEN * (*) (13.03.2008 16:06:42)

Так все таки где примеры? Простые и понятные, а то mpd написаный на С слишком на низком уровне его юзает что бы сделать какие-то выводы. Все примеры что я нахожу сводятся к netgraph-netflow

> Так все таки где примеры?

/usr/share/examples/netgraph

>> Обосновал (в первом посте): 200 кадров в секунду, 1000 физических запросов к диску в секунду.

>Это не обоснование. В частности, для вывода 1 кадра может понадобиться 2 системных вызова :D Ну и вообще - серверные нагрузки, где одновременно работа/т диски, сети, таймеры...

Тогда надо статью писать, иначе меня не понимают... тебе пофлеймить хочется? или все же укажешь на мои ошибки?

> для вывода 1 кадра может понадобиться 2 системных вызова

может там будет этак 10К запросов на заливку прямоугольников, отрисовку линий, перемещение областей, вращение-движение полигонов -- и надо это векторизовать, а дальше код, который проверит -- готова ли видяха? а если готова, то жри-большой-чанк-openGL-комманд. Может быть даже 10 чтений из портов будет, но не 10К -- это важно.

И вот этих жри-большой-чанк-openGL-комманд нужно не больше 200 в секунду, а всякие мелочи по поводу того, готова ли принять это видяха -- можно вообще не считать.

> диски

на самом деле диск физически дергать надо еще реже чем раз в 1мс

т.е. больше 1000 НЕПОСЛЕДОВАТЕЛЬНЫХ секторов мы все равно не отдадим в секунду, а 1К последовательных сектора идут почти одним запросом к порту (ну допустим 10 невекторизуемыми запросами, но не 1К невекторизуемых запросов).

> сети

>> и специфичные баги vmsplice

>Да ты видел эти "специфичные баги"? Обычная, скучная пропущенная проверка доступа.

Специфичность не в ошибке, а в том, что она в специфичной функции vmsplice, которая никому не нужна, кроме тех, у кого высоконагруженный 1Г интрефейс или 10Г. А таких < 1% от всех, ибо на десктопах такого нет, на хостинге впролне тянет 100М, апликухи проц сожрут гораздо раньше, а оставшихся <1%.

Вот оставшиеся 1% пусть юзают линукс, тем более им драйвероперделки не нужны и их не уронят, либо кто-то может все же сделает к микроядру аналог модулей линукса, для этого 1%.

> таймеры

Если тебе нужна точность лучше 0.5 мс в таймерах -- это уже специфичная система, и я не против, если такой таймер будет вкомпилен в самопальное ядро миникса, а не идти сервисом.

А если меньше -- то обойдутся 1К прерываний.

> ...

троечие? пока имеем видяху, диски, сеть, таймеры. Еще что грузит?

>> Вот и надо протестировать: читаем весь жесткий диск и замеряем расход ЦПУ на это.

>И что именно это замеряет?

Хм. А я думал что все и так ясно. Это замеряет не "преимущество обобщенной монолитной системы над обобщенной микроядерной", а "преимущество практически реализованной монолитной системы над практически реализованной микроядерной". Линукс вылизан, и его сильно ускорить сложно, миникс вполне возможно не вылизан -- но мы об этом пока забудем и сравним что есть.

> Ты упорно не считаешь 2 "достаточно похожих" драйвера для разных ОС.

2 "достаточно похожих" драйвера нужны Танненбауму, а не мне!!!

Если выяснится, что на существующем драйвере миникс сливает в 5 раз, я скажу что он сырой. Если в 2 раза, то задумаюсь. А если на 40%, то его можно ставить на сервер... когда будет аналог iptables.

Кстати, у академичиских изделий часто бывает один недостаток -- они делаются на чисто-каком-либо подходе, хотя для практике чаще всего нужны возможности гибридизации с чем-то другим хотя бы на уровне "добавил сишный исходник и вкомпилил свой 10Г драйвер в микроядро".

С другой стороны, вполне возможно вообще отказаться от поддержки таких прожорливых устройств в минике -- для этого будет линукс... а ОС от ядра не должно зависеть -- вот тебе позикс для С, и нефиг юзать что-то специфичное, вот тебе дебиан (который кстати есть на БСД-шных ядрах и на хурде). Это конечно чуть-чуть не так (например, функциональность ip фильтра на линуксе не точно повторяется функциональностью ip фильтра БСД и С апи там конечно разное), но жить это не слишком мешает.

> Кстати, у академичиских изделий часто бывает один недостаток -- они делаются на чисто-каком-либо подходе, хотя для практике чаще всего нужны возможности гибридизации с чем-то другим хотя бы на уровне "добавил сишный исходник и вкомпилил свой 10Г драйвер в микроядро".

Да, "добавил сишный исходник и вкомпилил свой 10Г драйвер в микроядро вместо запуска его сервисом". Да, стандартный айпи фильтр a-la iptable к этому драйверу будет не применить, но его тоже можно вкомпилить -- оно даже и побыстрее работать будет любого netgraph, ибо снимается один уровень косвенной адресации. Ну нельзя будет на ходу придумывать фильтры... но это и не так важно, обычно меняются не алгоритмы фильтрации, а пакеты... да и придумать гуи прогу, генерящую сишный исходник -- не проблема.

s/обычно меняются не алгоритмы фильтрации, а пакеты/обычно меняются не алгоритмы фильтрации, а порты и списки ip адресов/

По топику. Кривым оказалось не ядро линуха а глибц http://www.kernel.org/pub/linux/kernel/people/npiggin/ebizzy/ebizzy.png