венда рулит как обычно :)
только конфигурация -- за firewall'ом с snort2pf на OpenBSD ;)
и скрипт киддисы пойдут нахер ;)

>ну работает это хыета, надо чтобы железно! ;)

железно и работает. уже полгода к ней не подхожу.

>ыгы. 15 минут. потом снет эту кодопоеботу нахер :)

ниасилил? =)

>производительность чего?
сеть например в OpenBSD одна из самых быстрых. и без
костылей типа поллинга и O(1)-shit там где не надо.

ы? может поведаете, как вы кроме обработки прерываний/поллинга будете получать данные от nic?
и где цифры, что "сеть например в OpenBSD одна из самых быстрых"?
И что вы скажете насчёт той же сети на smp?

>в linux вот 2.6 производительность сети действительно
убогая. даже на простой роутер пущать не хочется :)

опять же, цифры где?

>За _меньшие_ деньги можно взять Sun X4100 или похожее
железо от IBM/Dell и сделать на OpenBSD BGP сервер
масштаба крупного IX.

Если openbsd _поддерживает_ это железо. Опять же, X4100 - это двухпроцессорник, в который в максимальной конфигурации получается с 
4 ядрами. А с smp в опене жопа. лучше уж купить x2100.

>у Cisco _слишком_ слабые процы и _слишком_ мало памяти (за такие деньги)

с этим не спорю.

>Всё то же самое. только шина пошире. Но есть
PCI-X да и PCI-E сейчас активно набирает ход... Так что
Cisco перестает быть хоть каким-то сльным аргументом..

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

>CARP в опене на порядок лучше и стабильнее
чем где-либо, куда он был "спортирован", равно как и pf :)

аргументы?

Кстати говоря, отсутствие strlcpy/strlcat в не-BSD-системах очень раздражает. Почти так же, как отсутствие ключика -delete в GNU find :)

Итересно было бы узнать ФИО человека, который "решил быть трудным". Не поленюсь, напишу ему.

>strl* это "правильные" строковые функции

С чего вдруг они стали правильными,
во-первых их нет в стандарте, так что glibc никаким боком не должна их влключать,
а во-вторых это всего лишь полумера, обрезать неправильную строку это не выход.

http://sourceware.org/ml/libc-alpha/2000-08/msg00053.html

>>ыгы. 15 минут. потом снет эту кодопоеботу нахер :)
>
> ниасилил? =)

ыгы. срань :)

>ы? может поведаете, как вы кроме обработки прерываний/поллинга будете >получать данные от nic?

ты не понял. polling sucks. interrupts rules. при условии нормального
драйвера и нормального железа (bge, sk, fxp)...
пример дурного драйвера -- em, можите сами поглядеть :)

>и где цифры, что "сеть например в OpenBSD одна из самых быстрых"?

чисто субъективно :)  я мерить не стану.
просто поглядел в коды сетевых драйверов и стеков :)

>И что вы скажете насчёт той же сети на smp?

не влияет. а почему должна?

>>в linux вот 2.6 производительность сети действительно
>убогая. даже на простой роутер пущать не хочется :)
>
>опять же, цифры где?

дык -- preemtible и O(1) в sheduler всяко дадут тормоза в сети :)
это ж палка о двух концах. к тому же в линуксе драйверы сети
часто third party и слабо поддерживаются... в общем мне там сеть
вообще ничем не нравится.. бе и кю :/

>Если openbsd _поддерживает_ это железо. Опять же, X4100 - это
>двухпроцессорник, в который в максимальной конфигурации получается с 
>4 ядрами. А с smp в опене жопа. лучше уж купить x2100.

не, я не понял. smp -- всяко гут. в openbsd smp работает как
scheduling _процессов_ по процам а не потоков (как в нормальных
SMP системах). но тот же bgpd использует одно-процессную event-based
модель, так что ему от этого всё равно не тепло ни холодно..
а так -- будет разгрузка... а вообще в X4100 я просто так тыкнул :)
потому что это не принципиально. надо в каждом случае смотреть
что надо..

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

ээ, легко? PCI-X: 64bit * 133Mhz = 8512 Mbit/s в пике.

к тому же на это дело влияет не тупой bandwidth, а packet rate.

но не надо думать, что у cisco цифры заоблачные :) всяко не лучше
PCI-X. (чипы то там тоже PCI'ные :)

>>CARP в опене на порядок лучше и стабильнее
>>чем где-либо, куда он был "спортирован", равно как и pf :)
>
>аргументы?

1) всегда отстоет от OpenBSD;
2) нигде нету ftp-proxy и fstatd из OpenBSD;
3) CARP без pfsync -- бестолковая вещь, pfsync есть не везде.
4) наличие дополнительных "portability layers", как например
pfil(9).
5) тупо -- ошибки портеров (примеры есть в changelog NetBSD
например).

хватит?

s/отстоет/отстает/
s/fstatd/fstated/

> в openbsd smp работает как scheduling _процессов_ по процам а не потоков (как в нормальных SMP системах)

IMHO весьма спорное утверждение. не столько в плане OpenBSD, сколько из-за утверждения, что ядро нормальной системы не должно планировать потоки. в идеале, планировщик должен планировать именно потоки [а процесс уже суть контейнер]. другой вопрос, что при кривой реализации это скорее всего будет дико тормозить.

// wbr

> в идеале, планировщик должен планировать именно потоки

дык я о том же :)
может к 4.0 сделают RTHREADS, тогда могут (имхо) автоматом шедулится
потоки, потому что rfork :)

>Если openbsd _поддерживает_ это железо.

OpenBSD достаточно хорошо поддерживает стандартное железо.
Да и нестандартное тоже местами (например IPMI, ESM, I2C, ISA sensors).

не надо думать что поддержка железа OpenBSD на уровне 1995 года :)

может быть для какой-то суперновой мамы придется заюзать -current
(так бывало во времена пререлиза 3.9), но пока 3.9 достаточна
для большинства вещей..

вот кстати например, меня удивило отсутствие в 2.4.32 поддержки
VIA VT6410, пришлось руками делать. не критично, но OpenBSD давно
уже его суппортит :/

так что так сказать -- it depends.

> (так бывало во времена пререлиза 3.9)

вообще говоря в любые времена пререлиза :)

s/fstated/ifstated ;)

> s/fstated/ifstated ;)

да ё, чего-то мне не дается это написать правильно :)
не пользуюсь им :)  (шепотом: это костыль! ;)

Спасибо.

Товарищ действительно трудный. Лично мне эти функции нужны:

1. Для логов. Не влезет, так и чёрт с ним.

2. return value рулит, особенно когда его проверяешь. :) Опять же, если не влезет, то я об этом сразу узнаю и тогда уже буду что-то предпринимать. Так гораздо проще и удобнее, чем проверять длину строки заранее.

Вроде бы, очевидные соображения.

Тут боюсь моё письмо не поможет :)

>ты не понял. polling sucks. interrupts rules. при условии нормального драйвера и нормального железа (bge, sk, fxp)... пример дурного драйвера -- em, можите сами поглядеть :)

О боже... а теперь включи моск: на гигабите в тебя швыряются пакетами по 40 байт. Твоя сетевуха при этом будет генерировать более 3млн прерываний. В случае поллинга она этого делать не будет.

>чисто субъективно :) я мерить не стану.

круто. офигенный технический аргумент.

>дык -- preemtible и O(1) в sheduler всяко дадут тормоза в сети :)

preempt отключается. Насчёт шедулера: если он такой тормоз, но нафиг во freebsd начали делать ULE?

>Лично мне эти функции нужны:

Но причем здесь glibc?
Eсли вы хотите чтобы ПО с strl* было портабельно,
добейтесь включения их в какой-либо стандарт,
включения в конкретные библиотеки ничего не решит,
а до тех пор прдется их таскать с собой.

>1. Для логов. Не влезет, так и чёрт с ним.

snprintf ?

>) Опять же, если не влезет, то я об этом сразу узнаю и тогда уже буду что-то
> предпринимать. Так гораздо проще и удобнее, чем проверять длину строки заранее.

Ну я почему-то уверен, что если посмотреть на примеры использования
strl* то в большинстве случае результаты игнорируется, вне зависимости,
плохо это и хорошо, вот этого и опасается разработчик glibc.

>Тео - респект! Он как и дядя RMS борется за открытость кода драйверов, предоставляемых вендорами девайсов.

Не вижу ничего плохого в бинарных видео драйверах. Они работают. Что ещё надо? Не надо ломать API и всё будет отлично.

Я в целом понимаю его опасения, но из таких вот соображений можно вообще запретить пользоваться C. И тоже не без оснований.

Ведь уже есть strncat - её тоже запретить? Чем она лучше-то? Там тоже можно сначала проверять длину строки. А криво писать не запретишь.

И путь в стандарт как раз и лежит через общераспространённые библиотеки. Сначала все, кроме самых упёртых, начинают этим пользоваться, а затём это фиксируется в стандарте.

Можно конечно определять strlcpy/strlcat в самой программе (что собственно и приходится мне делать для портабельности), но как там кто-то уже сказал, мало хорошего таскать с собой половину libc (цитирую по дырявой памяти). И мне не нужна такая уж сильная портабельность, я был бы вполне счастлив, если б они, кроме BSD, появились бы в linux'ах (то есть, на практике, в glibc).

> О боже... а теперь включи моск:

О боже, я не думал что говорю с идиотом :)

Включи моск: нормальные сетевухи имеют fifo по 128-256k
и SDRAM на борту по 1-2-4 Mb. А также крутые механизмы
Interrupt Migitation.

Ты когда нибудь делал HiPerf рутер на PC?? Ты хоть раз
читал freebsd-performance для таких неосторожных заявлений?

парень, иди почитай, да? а потом приходи.

> preempt отключается. Насчёт шедулера: если он такой тормоз,
> но нафиг во freebsd начали делать ULE?

а кто тебе сказал, что сеть от этого станет работать лучше?
вообще говоря это делается для того, чтобы на этой железяке
еще что-то userland'овое сносно работало.

но для рутера это непригодно.

s/Migitation/Mitigation/

whatever, it's all the same for you, morronz!

strl действительно хорошая штука. Кто не знает, тот отдыхает: http://www.courtesan.com/todd/papers/strlcpy.html

Можно и не таскать с собой реализации strl*, а просто аккуратно пользоватся strn*, но... "человеческий фактор".

strn* требуют обвязки, просто больше приходится писать. Из-за этого они не выполняют своего основного предназначения.

Функция должна выполнить свою работу сама и целиком, а я должен просто проверить возвращённое ею значение, а не маяться дополнительной дурью. Иначе я лучше буду нормальную функцию с собой таскать.

>> pf? нафига? iptables есть.

>1. Тормозит на изменении правил 2. Является ipchains. В каком месте там tables? 3. shaper пристёгивается отдельно

1. На нескольких тысячах тормозит, но сомневаюсь, что pf при этом не будет тормозить. 2. ipchains и iptables _абсолютно_ разные системы. 3. shaper не имеет никакого отношения к _фильтрации_ трафика, чем занимается netfilter. tc (aka traffic control over qdisk) умеет контроллировать ширину канала каким угодно способом.

>> carp/ есть аналог - название если очнеь надо - могу описктаь в домашних заметках.

>А попробовать перед тем как предлагать религия не позволяет? 1. user-space 2. carp создаёт виртуальный интерфейс 3. на практике с vrrpd время переключения в минуту не покажется таким уж большим

Не несите ерунду. Ядерный carp _отлично_ работает, carp из userspace также работает как и в OpenBSD. Никаких виртуальных интерфейсов и т.п.

>> ipsec? не смешите...:)

>ctl!

Штурман, приборы? 42. Что, 42? А что приборы?

Обмен ключами работает, интерфейс с kernel sadb работает, механизм съема статистики есть. то нужно-то?

> hostapd? это что такое? wi-fi что ли? у меня работает в лине

Что работает? AP?

>шутник он, однако.. > >---cut--- >Well it is still early in the 4.0 cycle. There are some crazy projects being worked on, but we will have to see what is ready for release. I believe that some level of ACPI support (maybe battery support, maybe at least better interrupt routing) will make it. And who knows what else :) ---cut---

>доступ к ACPI - это несомненно прорыв вперед :)))

А то :) Они же борются за чистоту кода, пожтому не могут использовать интеловскую реализацию.

Александр Юрченко (grange__openbsd.org) в этом направлении очень активно работает.

>klalafuda * (*) (03.05.2006 11:25:16)

>Мне кажется всё лучшее что могло перекочевать из OpenBSD в Linux уже перекочевало. Остались только песенки про бинарные дрова и велосипедостроение на тему GNU софта.
>Camel (*) (02.05.2006 21:48:31)

Ну кажется ... ну с кем не бывает :)

OpenBGPd - покажи ка порт на линуск - а оно РУЛЬ!
Ну и по мелочи аллокатор памяти там. pf-ы всякие ....

>> pf? нафига? iptables есть.

>Не, pf симпатичнее. Но! Когда доделают до готового состояния nf-HiPAC (http://www.hipac.org/), вот тогда будет и на нашей улице празник. :)

hipac никогда не доделают, iptables настолько мощная система, что с ней не может тягаться ни pf, ни hipac, а поэтому в hipac (как и в pf) всегда будет только часть функциональности iptables, но с другой стороны iptables становятся неповоротливыми и возникают проблемы, например при обновлении очень большого количества правил, хотя в грамотной системе много правил никогда не кладутся в одну таблицу, а разбивается на дерево.

>atrus *** (*) (03.05.2006 11:36:51)

>pf выруливает у iptables как Unix у DOS. попробуйте сами сделать ассиметричный роутер (2xupstream, 2-3 - в LAN) на линукс и openbsd и поймете безбрежную разницу в удобстве и функциональности.

И что здесь настраивать? Все очнь просто с помощью iptables/tc.

>carp у опена в ядре. ucarp -- усерландовый отстой. vrrpd - усерландовый отстой под freebsd.

Ядерный carp есть для Linux. Не в vanilla, но как модуль.

>ipsecctl -- тула для управления ipsec flows или isakmpd. не знаю почему toxa его привел. мне от него ни тепло ни холодно -- просто другой взгляд на проблему конфигурирования ipsec туннелей (взамен старому ipsecadm).

И что? У RH есть графическая морда для конфигурирования туннелей - что может быть проще щелкания мышкой по меню?

>hostapd и wifi точки доступа. насчет мощности -- бывает по- всякому, бывают мощные AP, бывают дохлые AP и мощные карточки. насчет hostapd -- это средство управления роумингом wifi-клиентов IAPP (802.11f) -- с фильтрами, привязками и так далее..

hostapd везде один и тот же.

>bgpd -- сейчас это полнофункциональный bgp-4 сервер с привязкой к pf и _использующийся_ уже на многих рутерах в европе (http://www.openbgpd.org/users.html) и у нас :) bird -- жалкое подобие академического IGP/EGP сервера. на практике им пользуются очень мелкие конторы и _мечтают_ перейти на что-либо более серьезное. zebra/quagga -- стабильность -- 0, качество имплементации -- 0. it's dead.

quagga достаточно активно разрабатывается, но здесь я соглашусь, что bgpd проще, удобнее и наверное лучше.

>w^x и PaX -- ыгы в линухе это даже раньше, только: 1) не в vanilla; 2) не комплексное (в OpenBSD это далеко не единственное средство) + в OpenBSD есть такое понятие как аудит кода системы. consistency панимаш. в Linux даже понятия такого нету :(

Аудит :) Это вы рекламы наслушались?..

>strl* это "правильные" строковые функции, разработанные проектом openbsd во время первого аудита системы (около 96-97гг). помоему drepper'а долб$%б@ распинали чтобы он включил это в glibc. в altlinux/openwall это дело было сразу...

:)) да, добавить 0 в конец - это _правильная_ функция... Хочется использовать - вперед, аудит в openbsd в этом направлении заключался в смене strcpy на strlcpy.

>вообще говоря в линукс раздрожает только одно -- низкое качество кода системных компонент. если в linux kernel (особенно после того как redhat и иже с ними стали платить за это дело) стали приводить порядок, то userland -- просто страшнючий.

userland везде один и тот же, хотя open иногда делает _свои_ _хорошие_ вещи, но только иногда. В целом все одно и то же.

>> А меня в OpenBSD раздражает низкая производительность.

>производительность чего? сеть например в OpenBSD одна из самых быстрых. и без костылей типа поллинга и O(1)-shit там где не надо. freebsd между прочим в 7-current тупо переписывает то, что в опене сделано :)

>в linux вот 2.6 производительность сети действительно убогая. даже на простой роутер пущать не хочется :)

Не несите чушь. Open также умирает при огромном количестве irq как и freebsd и linux, только в последних есть polling/napi, а в open производительность стека/userspace/vm не позволяет использовать сетевые карточки на полную. Возмите 2 гигабитных линка и зафлудите их 60байтными пакетами из аппаратного генератора трафика - система умрет, а для роутера это должна бытьь вполне рабочая ситуация. Тео высказывался по поводу polling - дескать это им не нужно... Конечно не нужно, раз все равно с нагрузкой справитсья не могут.

>> Очнитесь. CARP есть в виде LKM для linux

>Да мне незачем. CARP в опене на порядок лучше и стабильнее чем где-либо, куда он был "спортирован", равно как и pf :) Это признают сами разработчики этого, куда уж мне до них (;

Разработчики чего? pf? Может быть. Рассуждать о стабильности carp может только человек, который никогда его не использовал - это _чрезвычайно_ простой механизм, все ошибки в нем уже давно найдены.

>я выбираю те факты, которые говорят, что Linux -- ни разу ни ОС, а конструктор. это и плохо и хорошо, но мое _личное_ мнение (основанное на _моем_ опыте) говорит, что с OpenBSD общаться в _разы_ быстрее и проще. Мне лень заниматься ежедневным мозгоебством на предмет левых патчей и прочего.

Просто потому, что вы никогда не разбирадись в Linux. Кому-то сложно сделать что-то в open, кому-то в Linux.

>>ы? может поведаете, как вы кроме обработки прерываний/поллинга будете >получать данные от nic?

>ты не понял. polling sucks. interrupts rules. при условии нормального драйвера и нормального железа (bge, sk, fxp)... пример дурного драйвера -- em, можите сами поглядеть :)

Вы несете чушь. Одно прерывание на пакет - система умрет. Одно прерывание на несколько пакетов - очень высокие задержки. Выход здесь в napi и polling.

>>и где цифры, что "сеть например в OpenBSD одна из самых быстрых"?

>чисто субъективно :) я мерить не стану. просто поглядел в коды сетевых драйверов и стеков :)

"поглядел в коды стеков" - это в мемориз :)

>>И что вы скажете насчёт той же сети на smp?

>не влияет. а почему должна?

Это в open не влияет, т.к. никогда не достигала максимума. Должна хотя бы затем, что обработка прерываний может быть на одном процессоре, а userspace socket processing на другом.

>>>в linux вот 2.6 производительность сети действительно >убогая. даже на простой роутер пущать не хочется :) > >опять же, цифры где?

>дык -- preemtible и O(1) в sheduler всяко дадут тормоза в сети :)

Разговор стоит прекратить, т.к. вы не понимаете о чем говорите.

>это ж палка о двух концах. к тому же в линуксе драйверы сети часто third party и слабо поддерживаются... в общем мне там сеть вообще ничем не нравится.. бе и кю :/

:) все понятно...

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

>ээ, легко? PCI-X: 64bit * 133Mhz = 8512 Mbit/s в пике.

Еще скажите. что open это умеет. Максимальная производительность forwarding был показана в Linux на smp системе, поищите ссылку в архивах linux-netdev, автор Robert Olsson.

>>>CARP в опене на порядок лучше и стабильнее >>чем где-либо, куда он был "спортирован", равно как и pf :) > >аргументы?

>1) всегда отстоет от OpenBSD; 2) нигде нету ftp-proxy и fstatd из OpenBSD; 3) CARP без pfsync -- бестолковая вещь, pfsync есть не везде. 4) наличие дополнительных "portability layers", как например pfil(9). 5) тупо -- ошибки портеров (примеры есть в changelog NetBSD например).

pfsync в Linux - ct_sync, ftp-proxy это что? Случаем не то, что умеет connection tracking много лет как?

rtc -- ваш новый клоун?

парень, polling мертв. поговори с дядями с рамблера (glebius@ например)
и подумай головой. polling нужен в случае убогого драйвера, который не
в состоянии управлять устройством, способным к interrupt mitigation.

conn. tracking это да, но я говорил про pf. в линуксе есть pf?

iptables -- мертвое дерьмо. абсолютно не human usable. выкини его
к херам :)

> Еще скажите. что open это умеет.

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

> Разговор стоит прекратить, т.к. вы не понимаете о чем говорите.

А я с вами его и не начинал :) Вы же не знаете о чем идет речь...

>не влияет. а почему должна?

> Это в open не влияет, т.к. никогда не достигала максимума.
> Должна хотя бы затем, что обработка прерываний может быть на одном
> процессоре, а userspace socket processing на другом. 

what is a bullshit? ты жопой думал, когда писал? :)
ну правда. мы говорим про роутер, роутер как минимум не создает
никаких сокетов. go fuck yourself lamer.

> Вы несете чушь. Одно прерывание на пакет - система умрет.
> Одно прерывание на несколько пакетов - очень высокие задержки.
> Выход здесь в napi и polling.

неа, вот вы как раз и не правы. человек говорящий что polling это
круто для сети заведомо неправ :) Это легко понять логически для
стеков и драйверов BSD (в linux хер его знает что там сделано), но
даже правктически это тупо _видно_ :)

дядя RealTimeCounter поучите меня глупого уму разуму, только 
не переборщайте :) Мы тоже не пальцем деланы.

>парень, polling мертв. поговори с дядями с рамблера (glebius@ например) и подумай головой. polling нужен в случае убогого драйвера, который не в состоянии управлять устройством, способным к interrupt mitigation.

Нет, вы явно не работали на прктике с такими устройствами, раз это говорите. В e1000 есть interrupt mitication, так если его выставить достаточно большим, то для bulk transfer это помогает (и можно про бенчмарки говорить), но сессии, где посылается маленькое количество сообщений начинают заметно тормозить. Поэтому сами разработчики из Intel не рекомендуют менять значение по умолчанию. А вы мне рассказываете о каком-то glebius@ и рамблере :) polling это единственный способ работать в любой ситуации, а не тогда, когда хочет выделить лишь один usage case.

>conn. tracking это да, но я говорил про pf. в линуксе есть pf?

>iptables -- мертвое дерьмо. абсолютно не human usable. выкини его к херам :)

Аргументация на высоте, впрочем, чего я ожидал от анонимуса с поверхностным знанием обсуждаемого предмета.

>> Еще скажите. что open это умеет.

>дядя, ОС не должна специально суппортить что-либо в PCI-X, чего нет в PCI, поскольку они программно-совместимы.

Я говорил о скорости передачи. Open может делать 1gb/s маленькими пакетами из userspace? Ответ - нет, и это не теоретические изыски, которыми вы здесь брызжите, а факт.

>>>не влияет. а почему должна?

>> Это в open не влияет, т.к. никогда не достигала максимума. > Должна хотя бы затем, что обработка прерываний может быть на одном > процессоре, а userspace socket processing на другом.

>what is a bullshit? ты жопой думал, когда писал? :) ну правда. мы говорим про роутер, роутер как минимум не создает никаких сокетов. go fuck yourself lamer.

:) слив засчитан. думать вы не умеете.

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

>> Вы несете чушь. Одно прерывание на пакет - система умрет. > Одно прерывание на несколько пакетов - очень высокие задержки. > Выход здесь в napi и polling.

>неа, вот вы как раз и не правы. человек говорящий что polling это круто для сети заведомо неправ :) Это легко понять логически для стеков и драйверов BSD (в linux хер его знает что там сделано), но даже правктически это тупо _видно_ :)

Много слов, но ни одного аргумента. Я выше написал про interrupt mitigation и позицию intel по этому вопросу. так же вы не смогли объяснить, в чем проблема polling, отсюда можно сделать вывод, что вы слабо знакомы с предметом.

>И что? У RH есть графическая морда для конфигурирования туннелей - что может быть проще щелкания мышкой по меню?
>rtc (*) (03.05.2006 21:00:14)

A H T U N G !!!!!
Линуксоиды все же признались! :) А то все console - console ... :-)

>>И что? У RH есть графическая морда для конфигурирования туннелей - что может быть проще щелкания мышкой по меню? >rtc (*) (03.05.2006 21:00:14)

>A H T U N G !!!!! Линуксоиды все же признались! :) А то все console - console ... :-)

В RH консоли уже нет. Шутка.

Блин - хорошая шутка то, rtc, только грустая ...
С такими темпами ее похоже в самом деле уберут :(

Топик _on_ :
Если честно - то OpenBSD ___ну очень хороша___ как router / firewall ...
Но (раз уж честно :) - __только__ как это ...

> В e1000 есть interrupt mitication, так если его выставить достаточно большим, то для bulk transfer это помогает (и можно про бенчмарки говорить), но сессии, где посылается маленькое количество сообщений начинают заметно тормозить.

Ой, а почему?

(Извините, что вмешиваюсь в интеллектуальную беседу)

>Топик _on_ : >Если честно - то OpenBSD ___ну очень хороша___ как router / firewall ... >Но (раз уж честно :) - __только__ как это ...

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

И Open движется в этом направлении - во freebsd бардак, в netbsd вообще не компилируются регулярные сборки (а в коммитах прочел, что они импортировали xml в ядро), dragonfly какой-то полумертвый мух. Linux хорош. Действительно хорош, но можно быть лучше.

>> В e1000 есть interrupt mitication, так если его выставить достаточно большим, то для bulk transfer это помогает (и можно про бенчмарки говорить), но сессии, где посылается маленькое количество сообщений начинают заметно тормозить.

>Ой, а почему?

Грубая модель: вы работаете с TCP, послали syn - один пакет, а приемная сторона генерирует прерывание только для каждых 3 пакетов. При этом ваш syn висит и будет перепослан 2 раза, после чего только приемная сторона ответит syn+ack.

Конечно, в реальной жизни все несколько иначе и сетевые карты работают не совсем так, но люди, менявшие IMR для e1000 и пользующиеся дубовыми сетевыми отладчиками (которые работают по странному протоколу с маленькими пакетиками с обязательным подтверждением выше TCP), начинали выть от тормозов. Собственно, можно поискать в архивах linux-netdev.

>Грубая модель: вы работаете с TCP, послали syn - один пакет, а приемная сторона генерирует прерывание только для каждых 3 пакетов. При этом ваш syn висит и будет перепослан 2 раза, после чего только приемная сторона ответит syn+ack.

Вы уж очень угрубили.

>люди, менявшие IMR для e1000

А под IMR что в виду имелось?

>>Грубая модель: вы работаете с TCP, послали syn - один пакет, а приемная сторона генерирует прерывание только для каждых 3 пакетов. При этом ваш syn висит и будет перепослан 2 раза, после чего только приемная сторона ответит syn+ack.

>Вы уж очень угрубили.

Это же пример. В e1000 используется не такая модель. Там прерывание "откладывается" на определенное время, и если за это время придут еще пакеты, все равно прерывание будет только одно.

>>люди, менявшие IMR для e1000

>А под IMR что в виду имелось?

"Interrupt Throttle Rate", как раз описанный выше механизм.

Поллинг в такой ситуации спасает? :)

Видимо, про interrupt mitigation вам действительно очень грубо объясняли. В интеловских реализациях, во всяком случае, есть механизмы, позволяющие не допускать таких патологических случаев.

>В интеловских реализациях, во всяком случае, есть механизмы, позволяющие не допускать таких патологических случаев.

и что же за механизмы?

http://info.iet.unipi.it/~luigi/bsdcon01/polling/mgp00013.txt

Interrupt mitigation
Limit the max rate at which a card can generate interrupts.
Built-in in some cards (recent 21143, fxp with new microcode)
Can be emulated in software (have patches for intr_machdep.c), disable individual interrupt lines till next clock tick.
Pros and cons
no need for per-device modifications
partly reduces interrupt overhead
still potentially subject to livelock and responsivity problems;
when interrupts are shared, all devices on the same line are delayed;

переводить не надо?
особенно строчку: partly reduces interrupt overhead
?

Ну-ну, а ты суешь текст про костыль, который вместо хардварного механизма придумывают. Не все, что нагугливается, к месту.

Интеловские доки почитать не судьба?

bgp

> bird -- жалкое подобие EGP сервера. на практике
> им пользуются очень мелкие конторы и _мечтают_ перейти на что-либо
> более серьезное
bird - достаточно нормально делает свою работу с 3xFV BGP с вообщем-то небольшим расходом памяти (OSPF - не знаю, не использовал, у томичей какие-то грабли с ним были - я знаю), а в чём проблема у Вас была с ним? Или так, лужи газифицируете?
Меня особенно в нём привлекала возможность написания фильтров-правил на нормальном, вменяемом, C-подобном языке, а не каком-то убогом птичьем.
теперь по поводу "более серьёзного" - у толстых дядей AFAIK
используются Cisco, Juniper и Huawei. и соображения там совсем не те что здесь обсуждаются, а величина откатов.;)
Ну чесслово, глюков и там хватает!
А самое смешное было видеть завидущие глаза кошковода, мучившегося
с парой тысяч правил на Cat 6513 и смотревшего как легко и просто
примерно то же самое можно сделать в iptables.

>А самое смешное было видеть завидущие глаза кошковода, мучившегося >с парой тысяч правил на Cat 6513 и смотревшего как легко и просто >примерно то же самое можно сделать в iptables. А еще смешнее смотреть на линуксойдов, которые по пол тысячи правил клепают в iptables, которые можно несколькими строкаи в pf прописать. Не надо ляля iptables это неповоротливое чудовище, которе еще и глючное. Может быть оно конечно и аффигенно навороченное и там можно "дозаворачивать пакеты" (с), но как говорится "все гениальное просто" (с).

>Ну-ну, а ты суешь текст про костыль, который вместо хардварного механизма придумывают. Не все, что нагугливается, к месту. Интеловские доки почитать не судьба?

>переводить не надо? особенно строчку: partly reduces interrupt overhead

>Поллинг в такой ситуации спасает? :) Видимо, про interrupt mitigation вам действительно очень грубо объясняли. В интеловских реализациях, во всяком случае, есть механизмы, позволяющие не допускать таких патологических случаев.

В Интеловской реализации есть только единственный параметр, который регулирует throttling rate, о котором написано выше. Как он работает тоже описано выше, и для многих пользователей его увеличение ведет к непозволительным задержкам (latency) при передаче данных. Это факт, а не теортетические изыски, которые рассказывают анонимусы.

polling спасает и является единственным известным выходом из этой ситуации, т.к. позволяет динамически подстраиваться под загруженность сети и CPU, в то время как interrupt mitigation - нет.

Некоторые называют polling/napi программным interrupt mitigation, может быть это правильно.

Качество кода ядра linux =))

$ pwd
$ /usr/src/linux
$ uname
$ Linux
$ egrep -ir "( fuck)|( shit)" *

drivers/net/b44.c: /* ??? What the fuck is the purpose of the interrupt mask
drivers/net/declance.c: * v0.007: Big shit. The LANCE seems to use a different DMA mechanism to
drivers/net/macsonic.c: fuck did SONIC_BUS_SCALE come from, and what was it supposed
drivers/net/sunlance.c: * This was the sun4c killer. Shit, stupid bug.
drivers/char/ftape/compressor/lzrw3.c: /* Shit: we tried to decompress corrupt data */
drivers/sbus/char/Config.in: define_bool CONFIG_APM_RTC_IS_GMT y # no shit
drivers/scsi/NCR53C9x.c: * how bad the target and/or ESP fucks things up.
drivers/scsi/NCR53C9x.c: /* shit */
drivers/scsi/NCR53C9x.c: /* Be careful, we could really get fucked during synchronous
drivers/scsi/NCR53C9x.c: /* shit */
drivers/scsi/esp.c: * how bad the target and/or ESP fucks things up.
drivers/scsi/esp.c: * phase things. We don't want to fuck directly with
drivers/scsi/esp.c: /* shit */
drivers/scsi/esp.c: /* Be careful, we could really get fucked during synchronous
drivers/scsi/esp.c: /* shit */
drivers/scsi/esp.h: /* The HME is the biggest piece of shit I have ever seen. */
drivers/scsi/qlogicpti.h:/* Am I fucking pedantic or what? */

вот это и есть реальная оценка качества кода ядра =)
прям как у меня в подъезде...

> И Open движется в этом направлении - во freebsd бардак, в netbsd вообще не компилируются регулярные сборки (а в коммитах прочел, что они импортировали xml в ядро), dragonfly какой-то полумертвый мух. Linux хорош. Действительно хорош, но можно быть лучше.

пожалуй, на этом можно и закончить с вами "дискуссию" :)

// wbr

bgp

> можно несколькими строкаи в pf прописать
нельзя. точка. если б можно было бы - сделали бы - у Cisco ACL неплохи сами по себе, ведь задачи не ограничиваются только пропуском гигазов вареза и порнухи из интернета.

свинья

> sbus/char/Config.in: define_bool CONFIG_APM_RTC_IS_GMT y # no shit
свинья-то грязь найдёт!
между прочим - тут конкретно просто опечатка (typo)

>В Интеловской реализации есть только единственный параметр, который регулирует throttling rate, о котором написано выше. Как он работает тоже описано выше, и для многих пользователей его увеличение ведет к непозволительным задержкам (latency) при передаче данных. Это факт, а не теортетические изыски, которые рассказывают анонимусы.

Ню-ню. :) Факт, говорите? Спасибо, забавно было пообщаться :)