LINUX.ORG.RU

Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux


0

0

По результатам исследования проведенного Reasoning Inc. оказалось что реализация стека протоколов TCP/IP в Linux версии 2.4.19 имеет меньше дефектов чем реализации этого стека в нескольких коммерческих системах.

>>> Подробности

★★★★★

Проверено: green

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

>RTFM - Параллельные прямые по определению не пересекаются.
Во-во, только хотел написать.
А, вообще, это какой-то широкораспространенный миф про Лобачевского и пересекающиеся параллельные прямые. Кто знает, откуда это пошло?

del ()

Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2anonymous (*) (2003-02-20 19:18:29.02) aka ARia:

> Не-Евклидова геометрия:
> Аксиома параллельности:
> Через заданную точку можно провести не более, чем две прямые,
> паралельные данной.

RTFM -
Геометрия Лобачевского:
Через заданную точку можно провести сколько угодно прямых,
паралельных данной.

Геометрия Римана (в узком смысле; ее обычно называют сферической,
дабы отличить от гиперболической Лобачевского):
Через заданную точку нельзя провести ни одной прямой,
паралельной данной.

Оба они являются частными случаями неевклидовой геометрии.

> Знатоки блин.
No comments.

Die-Hard ★★★★★ ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

Ваааще :-) тюбики припухли :-)) публикуют, понимашь, АднАзнАчнА (c) 1993-2003 asoneofus, без указания авторских прав - вроде как даже и под GPL условие такое имееЦЦа :-)

Про знатоков TCP/IP ower Ethernet :-) кроме заголовков есть ещё собсссно IEEE802.3(куча реинкарнаций) - хрень такая, собссно ещё имеющая прямые накладные, типа преамбулы, пары адресов, нок, указателя длины пакета...., контрольной суммы (в принципе, фигня) и тайминги, интервалы ожидания, повторения передачи и прочей муйни - живущих ещё со времён 10-ки (и контроля джаббера в коаксиале :-)). Если стандарт не об ... эээ ... манывать, что допускают некоторые карточки, то вытянуть поток при 100 аннонсированных, на 80...85 (хотя, вериЦЦа с трудом) можно... :-) но 100 при 100 - это новость.... Схемку не подкините? :-) (софт не интересует в данном вопросе :--))))

asoneofus ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

PS ... хе, а вообще всю булеву (и программу) можно описать в функционально полном(? термин мож не тот?) базисе, к примеру 2И-Не :-)))) ...

asoneofus ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

to Die-Hard:
Сорри, не менее двух прямых
О Любых количествах ничего не говорится

ARia

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2 РТО (знатоку теории алгоритмов и алгоритмических языков)

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

А сами будете извиняться за не вполне корректные высказывания ?

>Советую почитать Бома и Джакопини, которые еще в 1965 году ДОКАЗАЛИ математически, что ЛЮБАЯ программа может быть построена с использованием трех блоков/конструкций:

Ваши слова ? Агоритм поиска в несортированной базе данных попадает

под Ваше определение "ЛЮБАЯ программа" ? Я думаю, что да.

Есть работа:

Р. Шпрэу, (Университет Амстердама, Нидерланды).

"Реализация квантового алгоритма поиска на основе источника одиночных

фотонов и классической Фурье-оптики".

Реализованный в эксперименте алгоритм позволяет найти любую запись в

несортированной базе данных из 32 записей всего за 6 обращений.

А теперь вопрос:

Опишите с использованием трех блоков/конструкций, из

приведенной Вами теоремы Бома и Джакопини алгоритм, который позволяет

найти любую запись в

несортированной базе данных из 32 записей за 6 обращений.

Саныч

Зы Я не физик-ядерщик, Вы мне льстите :)

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

>А теперь вопрос:
>Опишите с использованием трех блоков/конструкций, из
>приведенной Вами теоремы Бома и Джакопини алгоритм, который позволяет

А почему это только трёх ??

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

Что-то ты братец, посторянно шило с мылом сравниваешь ...

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

>А почему это только трёх ??

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

Что-то ты братец, посторянно шило с мылом сравниваешь ...

Нет это РТО, как всегда, не дал корректной формулировки.

>Советую почитать Бома и Джакопини, которые еще в 1965 году ДОКАЗАЛИ математически, что ЛЮБАЯ программа может быть построена с использованием трех блоков/конструкций:

1. Линейная последовательность действий - функциональный блок
2. Цикл с проверкой в начале - обобщенный цикл
3. Условный переход - двоичное решение

Конечно же, трех "ТИПОВ" блоков, самих блоков может быть любое число.

Саныч

anonymous ()

Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

anonymous (*) (2003-02-21 11:18:43.051) aka ARia:
> Сорри, не менее двух прямых
> О Любых количествах ничего не говорится

Значит, так.
"Физический смысл" для геометрии Лобачевского - именно в том,
что через точку проходит бесконечное кол-во различных прямых,
параллельных данной. Это - ТЕОРЕМА.

А АКСИОМА звучит так:
Через точку можно провести ДВЕ различные прямые, параллельные
данной.

Die-Hard ★★★★★ ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2 Саныч

Есть работа:

Р. Шпрэу, (Университет Амстердама, Нидерланды).

"Реализация квантового алгоритма поиска на основе источника одиночных

фотонов и классической Фурье-оптики".

Реализованный в эксперименте алгоритм позволяет найти любую запись в

несортированной базе данных из 32 записей всего за 6 обращений.

А теперь вопрос:

Опишите с использованием трех блоков/конструкций, из

приведенной Вами теоремы Бома и Джакопини алгоритм, который позволяет

найти любую запись в

несортированной базе данных из 32 записей за 6 обращений.

---------------------------------------------------------

Хм, если понимать под "обращением" считывание значения одной записи по номеру, то это НЕВОЗМОЖНО ни на какой архитектуре, хоть на фон Неймана, хоть на квантовом - ВООБЩЕ НЕВОЗМОЖНО.

Математика и информатика, как ее часть, вещь, понимаешь, универсальная. И отменить ее законы невозможно.

Что понимают под "обращением" авторы статьи неизвестно. скорее всего это вариант "параллельных вычислений", что-то вроде получения отклика ОТ ВСЕЙ БАЗЫ ДАННЫХ на некоторое воздействие, и вот за таких 6 "обращений" возможно найти запись.

Так что не говори глупости, уважаемый.

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

Так что не мороч людям голову и не позорься.

ignite ()

Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2anonymous (*) (2003-02-21 13:45:54.47) aka Саныч

Извини, но ты ОТКАЗЫВАЕШЬСЯ понимать, что тебе говорят.
Попробуй, перечитай ответы тебе еще раз, включив логическую компоненту
интеллекта :). Не читай между строк, не приписывай оппонентам злого
умысла - никто тебя не пытается дурить.

Бом и Джакопини показали, что
1. Любая блок-схема сводится к другой блок-схеме, состоящей только из
трех кирпичей;
2. Прохождение блок-схем эквивалентно классической машине Тьюринга.

Про кол-во шагов там не было сказано ни слова. И не надо аппелировать к
квантовым алгоритмам. Я выше приводил простой классический пример Кнута,
который вообще невозможно переписАть без goto c тем же числом проверок.





Die-Hard ★★★★★ ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

>Математика и информатика, как ее часть, вещь, понимаешь, универсальная. И отменить ее законы невозможно.

Универсальных математик не бывает.

А вот скажите пожалуйста, всегда ли отношение длины окружности

к ее диаметру равно числу ПИ ? Если нет, то когда это не верно ?

Справедлива ли геом. Евклида в НЕ Евклидовом пространстве ?

Механика Ньютона в релятивистком движении ?

Читем еще раз пост от РТО он пишет, что "ЛЮБАЯ программа" и т.д.

Я привел пример алгоритма, ну и запишите его в блок схемах,

терминах этих трех блоков/операторов, детерминированной машины

Тьюринга, вероятностной машины Тью. черта лысого и жопы с ручкой.

И тогда поймете почему не следует говорить _всегда_ и _любая_

И почему теоремы теории классических алгоритмов не всегда

справедливы в области других вычислений (не на машине Тью.)

Саныч

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2 Саныч

Упертый болван.

FULL STOP

ignite ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2РТО (и прочим апологетам машинок Тьюринга)

Ну что молчите? Андрей Анатольевич ?

Небось учили Вас, ~О(0.5 N) обращений надо сделать для решения

поставленной задачки.

Кнута не читал, но некоторые оценки знаю.

А тут чел. показал, что можно ~O (корень квадратный из (N))

операций сделать.

Зы: N - число записей. О - это О большое, что такое могу объяснить.

А может расскажете почему кван. алгоритмы дают экспоненциальный

выигрыш

в производительности по сравнению с классическими ?

Или корпорайт зомби менталитет не позволяет ?

Про преобразование им. товарища Фурье например.

Лосям пластмассовым, типа Die-Hard, ignite, ARia && легион

анонимирующих товасчсчей.

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

Так что не мороч людям голову и не позорься.

Ага, поучи свою жену щи варить. Ты сам ШКОЛЬНИК, ептыть.

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

хуев.

Читать нужно не только учебники и книжки, написанные старыми

пердунами,

но и on-line статьи.

А че так IBM парится ? Она сейчас лидер именно в этой области.

А правительство США ? Может назовете объем финансирования именно в эту

область ?

Саныч % --) пьяный по поводу "ДНЯ ЗАЩИТНИКОВ ОТЕЧЕСТВА"

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2ignite >Упертый болван.

А ты, клоун, посмотри почему РТО заткнулся.

Он небось при Советской власти учился, и экзамены

не за бабки сдавал. И Кнута читал и в тетрадочку конспектировал.

Зы Как в асме обойтись без jmp

movl #куда надо, %eax

push eax

ret

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

Саныч

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

to Саныч:

Протрезвей, не позорься

ARia

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2ARia

>to Саныч:

Протрезвей, не позорься

А вот скажите пожалуйста, всегда ли отношение длины окружности

к ее диаметру равно числу ПИ ? Если нет, то когда это не верно ?

С меня коньяк, если расскажете.

Зы: Предложение действительно до 21.02.03 20.00 моск. времени

потом коньяка уже не будет :)

Саныч

anonymous ()

Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2Саныч:
> всегда ли отношение длины окружности
> к ее диаметру равно числу ПИ ? Если нет, то когда это не верно ?
Не равно во вращающейся системе отсчета. С тебя коньяк, в Москве еще около
19.00

С праздником!

Die-Hard ★★★★★ ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

общая информация:
использовались компиляторы:
gcc --version
gcc (GCC) 3.2.3 20030219 (prerelease)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

/usr/bin/gcc --version
2.95.4

iccbin
intel C Compiler v 7.0

пороцессор AMD Athlon XP 1600+, palomino (по запросам мистера була :)

по поводу измерений: чтобы не ждать по 10 секунд для каждой опции
программы были модифицированы для получения время с использованием
gettimeofday. измерения проводились для N[n] = {1000, 1000, 1000};

для проверки было измеренно время при N[n] = {3000, 1000, 1000};
результаты отлично масштабируются --- ровно в 3 раза.

код измерения времени:
struct timeval tv0, tv1;
gettimeofday(&tv0, 0);
//...код...
gettimeofday(&tv1,0);
if(tv1.tv_usec < tv0.tv_usec) {
tv1.tv_sec-=1;
tv1.tv_usec+=1000000;
}
tv1.tv_usec-=tv0.tv_usec;
tv1.tv_sec-=tv0.tv_sec;
printf("%ld.%ld\n", tv1.tv_sec, tv1.tv_usec);


по поводу опций : помимо базовой -O3 измерялись времена для
-fforce-addr, -fforce-mem, -frerun-cse-after-loop, -frerun-loop-opt,
-fexpensive-optimizations, -fgcse, -fschedule-insns, -fschedule-insns2,
-march=i386, 486, 586, 686, (для icc -tpp5, 6, 7); -tpp7 всегда пролетает
на атлоне, что впрочем не удивительно :)

для gcc-3.2 побовалось также -march=athlon и athlon-xp, но как-то все время
оказывалось хуже чем для i686... видимо у gcc-team другой атлон :(
gcc -O3 dekart_kosenko.c && ./a.out
2.773040
gcc -O3 -fforce-addr dekart_kosenko.c && ./a.out
2.182999
/usr/bin/gcc -O3 dekart_kosenko.c && ./a.out
2.906139
iccbin -O3 dekart_kosenko.c && ./a.out
2.187541
iccbin -O3 -tpp6 dekart_kosenko.c && ./a.out
1.454919
для -tpp5 тоже-самое.
комментарии для этой версии программы: -fforce-addr gcc-2.95 не помогает, а
мешает(3.33s).

gcc -O3 dekart_deiksta.c && ./a.out
2.909395
/usr/bin/gcc -O3 dekart_deiksta.c && ./a.out
2.769920
iccbin -O3 dekart_deiksta.c && ./a.out
3.634750
iccbin -O3 -tpp6 dekart_deiksta.c && ./a.out
3.396527

комментарии по поводу этого варианта программы --- "шаш вправо, шаг
в лево и расстрел на месте" то-есть чуть-чуть меняем проц и/или опции и
пролетаем в производительности в 1.5-2 раза. лучший -march для gcc это
486 или 686 (одинаковые результаты) для icc -tpp6 опять-же если заглянуть
в код и/или ассемблерный листинг то можно заметить, что цикл этот состоит
из нескольких строчек и со свистом пролетает на современных конвеерах
длиной в 10 и больше стадий (у моего атлона по-моему 12)

общие замечания: loop unrolling на данных прогрпммах почти всегда убивает
производительность (почти это значит не убивает когда компилятор отказывается
его делать :), что в общем понятно учитывая "странность" цикла в виде
нескольких входов-выходов. в итоге кто руками развернет цикл в 2-4 раза тот
всех и сделает :) а если на асме то вдвойне... регистров хватает для
делания двух операций за один проход. в принципе можно заняться, но лениво :)

вроде ничего не забыл написать... надеюсь :)

HTH


преводились времена для комбинаций опций хоть как-то улучшающих результат
на фоне шума. разброс составляет порядка 10милисекунд.

-funroll-loops, -fomit-frame-pointer во первых включаются при -O3, а во
вторых в данном тесте не должны ни на что влиять (что и наблюдается на
практике) -funroll-all-loops влияет очень сильно, но не в лучшую сторону :)

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

да, забыл, если у кого есть сложившиеся варианты(особенно интересны рекурсивные и/или с разворотом цикла :) можно проверить.

HTH

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2ARia может поделитесь ссылками какими-нибудь на хорошие книжки/доки по оптимизации "высокоуровневой"? (вроде-бы вы говорили, что специализируетесь в этой области?) а-то с низкоуровневой более-менее знаком, а вот с высокоуровневой пробел, но интересно было-бы просветиться :)

заранее спасибо.

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

Очень просто
Partial Evolution
Очень неплохое введение http://www.dina.kvl.dk/~sestoft/pebook/pebook.html
Распараллеливание
http://parallel.ru/
Остальное относится к оптимизации функциональных
языков программирования, и, боюсь, вам не интересно.

ARia

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

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

да ну? и на process switching'е тоже?

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2 Die-Hard

>Не равно во вращающейся системе отсчета.

Это типа на земном шаре ? Ты что инопланетянин :) ?

Саныч

anonymous ()

Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2Саныч:
> Это типа на земном шаре ?
Точно! Ты не поверишь, но отношение длины экватора к соответствующему
большому диаметру МАТЕМАТИЧЕСКИ меньше Пи. Правда, очень на немного.
Принимая, что длина экватора составляет 40000 км и обращается Земля за
24 часа, а скорость света равна 300000 км/ч, получаем, что за счет
лоренцева сокращения отношение длины экватора к его диаметру равно
3.141592653586 против Пи с той же точностью
3.141592653590

Die-Hard ★★★★★ ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2Die-Hard

Преобр. Лоренца линейно и переводит окружность в эллипс. Так что не

вполне корректно.

Саныч

anonymous ()

Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2Саныч
> Преобр. Лоренца линейно и переводит окружность в эллипс.
Уффф...

Итак, бесконечно тонкий обруч крутится вокруг своего центра в своей плоскости.
Радиус обруча не испытывает лоренцева сокращения, поскольку он ортогонален
3-скорости. А сам обруч (каждый его бесконечо малый сегмент) испытывает
лоренцево сокращение за счет линейной скорости. В результате его полная длина
оказывается чуть меньше, чем такого же обруча в состоянии покоя.

Это классический пример того, как в ускоренной системе отсчета
4-геометрия остается (псевдо)-евклидовой, в то время как 3-геометрия,
соответствующая реальному физическому 3-пространству, приобретает
кривизну.

Die-Hard ★★★★★ ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

Ди-Хард, не изголяйся :-) Всё одно - Саныч коньяк уже выжрал :-) Вот и отмазываеЦЦа :-)

asoneofus ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

Да сдается мне, что в нелинейной геометрии "выпуклый" радиус - "полюбому" длинноват будет? :)

sin_a ★★★★★ ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2 Die-Hard

>Это классический пример того, как в ускоренной системе отсчета 4-геометрия остается (псевдо)-евклидовой, в то время как 3-геометрия, соответствующая реальному физическому 3-пространству, приобретает кривизну.

Преобразования Лоренца справедливы только для инерциальных

систем отсчета. Если этот факт не принимать во внимание, то можно

привести еще массу пародоксов, типа пародокса близнецов.

Саныч

anonymous ()

Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2Саныч:

Не отмажешься! ;)

В отличие от парадокса близнецов, это - НЕ парадокс, а реальное физическое явление, наблюдаемое, например, на кольцевых ускорителях.

Я тебе "на пальцАх" показал, аппелируя к преобразованию Лоренца. В данном случае рассуждения были вполне корректны, и могут быть строго воспроизведены в рамках систем отсчета.

Берешь монаду с вращением, в которой обруч неподвижен вместе со спицами. Она неголономна, т.е. 3+1 разбиение невозможно сделать глобально, но для любого обруча ты могешь построить монаду, допускающую 3+1 разбиение в некоторой окрестности, целиком этот обруч содержащей.

Делаешь 3+1 разбиение (процедура, хорошо изученная математически), и считаешь тензор кривизны (четырехидексный) 3-пространства. И он будет не 0. Хотя, разумеется, кривизна (4-хзначковая) 4-пространства равна 0.

Die-Hard ★★★★★ ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2Die-Hard >В отличие от парадокса близнецов, это - НЕ парадокс, а реальное физическое явление, наблюдаемое, например, на кольцевых ускорителях.

Какие экспер. на кольцевых ускорителях показывают

что для окружности число ПИ другое.

А че такое монада ? И при чем тут тензор кривизны ?

Что вращ. обруч искривляет пространство ? А где должен быть

тогда наблюдатель ? А скорость света в его системе отсчета постоянна ?

Саныч

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2Die-Hard

Ладно, не парься. Я вот что имел в виду.

&#171;В 1897 г. Генеральная Ассамблея американского штата Индиана утвердила билль 246, согласно которому число "ПИ" (далее p) принималось равным 4&#187;

Саныч

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2Саныч:Ладно, так и скажи - коньяк зажал. :-)

Die-Hard ★★★★★ ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

Мужуки, поднапрягитесь есче малеха,нужно догнать тему до 600 msgs :)

MrBool ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

2mrbool: "Мужуки, поднапрягитесь есче малеха,нужно догнать тему до 600 msgs :)"

а чего сам не напрягесся? табе дали результы для атлонов, как просил... комментируй :Р

anonymous ()

Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

to anonymous (*) (2003-02-28 05:25:08.382) :

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

Ты себе представить не можешь как меня весь этот месяц лень
мучает 8)

MrBool ()

Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

>> Как нормальную нагрузку дали, так они и загнулось... Гы гы :) А другие ос под такой же накрузкой просто жить не будут =) Сам видел - у нти 4й BSOD вылетел, када сокеты кончились. А когдп по одному 10% из них траф приличный попер так вообще...

anonymous ()

Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux


> Ну ну видел я исходники разбора tcp проткола в Линухе(2.4.6) такого
> сраного кода в своей жизни до сих пор не встречал, как он работает
> хрен его поймет, туева хуча функций без названий и понятных
> заголовков, которые хрен знает что делают.

Всё там нормально написано. Просто многое спрятано за #define чтобы не засирать код. Сделано это было для нативной поддержки iptables.

> Зато в бзди (4.4) разбор tcp протокола закручен в рдну функцию в 2000
> строк с небольшим по моему. Очень красиво написан, правда с
> безусловными переходами, зато все понятно.

Вот за эти две тысячи строк в одной функции таким кодописателям руки надо отрывать еще в детстве.


PS: Какая еще операционка может похвастаться тем, что в Линухе называется NAPI? В данный момент любая БЗДя умрёт при нагрузке равной гдето окого полугигабита на 64 байтных пакетах из-за Interrupt poisoning. А Линух без проблем тянет бриджинг на полную мощьность.
На Фрю это тока сейчас собираются прикручивать и тестировать. Вроде как в Винде 2000 Мелкософт это прикрутил, но это я могу сказать по косвенным данным.

All the Best!
Mage.

anonymous ()

Re: Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

> GOTO это не более чем затычка для дыр в языке. Без goto 
> можно в 99% слачаях обойтись.

В Линуксе в сорцах постоянно используется goto out; и в том случае это оправдано. Потомучто проце в одном месте снимать лок, и код становится меньше, что для ядра очень важно. Так что в Линуксе это постоянная практика использования примерно вот такого кода:

int func()
{
     spinlock_t bla;
     int rc = SUCCESS;

     spin_lock ( &bla );

     if ( func1() )
     {
        rc = -ERROR;
        goto out;
     }
     bla-bla-bla
     if ( func2() )
     {
        rc = -ERROR;
        goto out;
     }
     bla-bla-bla
     if ( func3() )
     {
        rc = -ERROR;
        goto out;
     }
     bla-bla-bla
     if ( func4() )
     {
        rc = -ERROR;
        goto out;
     }
     bla-bla-bla

out:
    spin_unlock ( &bla );
    return rc;
}

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


All the Best!
Mage.

anonymous ()

Re: Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

> PS: Какая еще операционка может похвастаться тем, что в Линухе
> называется NAPI? В данный момент любая БЗДя умрёт при нагрузке равной
> гдето окого полугигабита на 64 байтных пакетах из-за Interrupt
> poisoning.
Linux сдохнет в livelock.
BSD хотя-бы polling использует, чтобы с interrupt storms бороться.

anonymous ()

Re: Re: Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux


Извините, а Вы в курсе что такое NAPI? Мне кажется что нет. И вообще
Вы в курсе последних изменений в ядре Линукса 2.5.7 и выше? Как раз-
таки в Линуксе с interrupt storms именно поллингом и спасаются. и в
livelock как раз-таки BSD сдыхают. Я могу тут долго аргументированно
спорить с приведением кусков кода из ядра Линукса, но я думаю что Вы
не будете меня слушать, а только орать что Линукс сакс. Потому как
вам это проще, не разобравшись в вопросе кричать - "Сакс и мастдай" ;)

У меня на компе сейчас лежат сорцы ядер многих операционок ( Hurd,
eCos, Linux 0.01, Linux 0.96c [я с неё начинал в начале 93 года],
2.5.46 [я делаю дополнения в сетевом леере для себя], 2.5.63
[текушщая на данный момент], текущая версия NetBSD, текущая версия
OpenBSD, текущая версия FreeBSD, ReactOS ). И я перековырял их все.

Поэтому я могу аргументировано приводить все за и против. Чему прошу
и Вас придерживаться.

Да, согласен, ядра Линукса до версии 2.4 отставали по многим
параметрам от BSD клонов, но сейчас ситуация изменилась с точностью
до наоборот. У Линукса более лучший планировщик задач (Инго Молнар
постарался на славу), убраны лимиты на количество процессов,
количество открытых файлов в системе, и так далее.

Для примера вот парочка ссылок:
http://lwn.net/2002/0321/a/napi-howto.php3 - как работает NAPI,
http://www.linuxshowcase.org/full_papers/jamal/jamal_html/napi2.html - здесь документ с графиками.

Я видел что какой-то парень из Италии имплементировал похожий подход
в конце 2002 года и приступил к тестированию, но что-то старик Гугль
не хочет мне отдавать тот линк. Вы можете поискать по
словам "interrupt mitigation BSD"
http://mail-index.netbsd.org/source-changes/2002/11/01/0066.html
Это ссылка на NetBSD что они имплементировали Tx interrupt
mitigation, но еще не имплементировали Rx interrupt mitigation, что
гораздо важнее. Вот тут ссылка на то что этого нету у OpenBSD -
http://archives.neohapsis.com/archives/openbsd/2002-09/1963.html

PS: ТАк что не надо "ля-ля", а то ведь "би-би" в размере катка переехать может. ;)

All the Best!
ComputerMage.

anonymous ()

Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

>У меня на компе сейчас лежат сорцы ядер многих операционок ( Hurd,
>eCos, Linux 0.01, Linux 0.96c [я с неё начинал в начале 93 года],
>2.5.46 [я делаю дополнения в сетевом леере для себя]
А какие именно дополнениея, если не секрет?

del ()

Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

Пишу файрвол в виде кернел модуля. Пришлось маленько врезаться в
нетворк лейер чтобы вклиниться до пакетных дамперов.

Сразу предвосхищу вопросы чем мне не нравится iptables: У меня другой
принцип построения и отработки правил и пакетов, даже не знаю с чем
сравнить ;)
Как допишу, попробую сделать сравнения на что жто похоже. ;)

Одно могу сказать - по предварительным тестам (правда грубоватые) -
он (с милионом соединений и правил) быстрее чем Checkpoint FW1 с
одним правилом и соединением. Но не буду загадывать, возможно и
ненамного быстрее. Когда всё допишу - там будет видно.

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

All the Best!
Mage.

ComputerMage ()

Re: Re: Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

to anonymous (*) (2003-03-04 23:36:20.314) Mage :

>В Линуксе в сорцах постоянно используется goto out; и в том случае это
>оправдано. Потомучто проце в одном месте снимать лок, и код становится
>меньше, что для ядра очень важно. Так что в Линуксе это постоянная >практика использования примерно вот такого кода:

Ну и чем же тобой приведенный код лучше нижеследующего ? :))
В этом варианте съэкономили на переменной и GOTO .

int func()
{
     spinlock_t bla;
 
     spin_lock ( &bla );

     if ( func1() )
     {
        spin_unlock ( &bla );
        return -ERROR;
     }
     bla-bla-bla
     if ( func2() )
     {
        spin_unlock ( &bla );
        return -ERROR;
     }
     bla-bla-bla
     if ( func3() )
     {
        spin_unlock ( &bla );
        return -ERROR;
     }
     bla-bla-bla
     if ( func4() )
     {
        spin_unlock ( &bla );
        return -ERROR;
     }

    spin_unlock ( &bla );
    return SUCCESS;
}

>Так что это очень часто используется и в данном случае оправдано,

"НЕСОГЛАСЕН !" (C) :)

>так как уменьшает возможность создания ошибки если изменилось
>имя переменной лока

:)))))))))))))))))))))) Мужик, ты понял че сказал ? :)

MrBool ()

Re: Re: Re: Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

>Ну и чем же тобой приведенный код лучше нижеследующего ? :))
>В этом варианте съэкономили на переменной и GOTO .


"Потомучто проце в одном месте снимать лок, и код становится меньше, 
что для ядра очень важно."

>>так как уменьшает возможность создания ошибки если изменилось
>>имя переменной лока

>:)))))))))))))))))))))) Мужик, ты понял че сказал ? :)

Гм, может он и не понял что он сказал, но я например понял ;-)


sseREGa ()

Re: Re: Re: Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

А кто будет оптимизировать размер кернела? Или он резиновый?

Зачем вызывать один и тот же блок множество раз если его можно вызвать в одном месте, все равно выходить. Я понимаю что по идее оптимайзер компилятора должен скопировать эти блоки в один и сделать тот же самый jmp, но я доверяю себе а не оптимайзеру, потому как он может и не прооптимизировать.

А если у Вас на выходе больше кода, то зачем его дуплицировать? А если Вы в этом коде сделали какую-то ошибку а протом везде прокопировали этот блок? Времени на отладку уходит гораздо больше. Прошли те времена когда платили за количество строк кода. ;))) И самое главное, когда я так пишу, я всегда знаю что у меня обработка ошибок и выход всегда в конце процедуры, следовательно мне не надо пересматривать всю процедуру на поиск проблемы. Куча ретурнов в большой функции это весьма неудобно с точки понимания и той же отладки.

>>так как уменьшает возможность создания ошибки если изменилось >>имя переменной лока

> :)))))))))))))))))))))) Мужик, ты понял че сказал ? :)

Хорошо я неправильно выразился и привёл неверный пример. Но то что я привел выше в этом сообщении выше подтверждает удобство goto. Я не призываю использовать goto направо и налево, но частенько это необходимо.

PS: Если Вы желаете меня переубедить, то приводите примеры не только на уровне Си, но и на уровне ассемблера, и как это будет воспринматься процессором, а так же нецелесообразность goto в данном случае. Я за 15 лет использования Си старался избегать goto, и использовал только где это необходимо, в таких случаях как я описал.

PPS: Я могу изменить своё мнение, но только в случае если мне аргументированно докажут что я не прав в том-то и том-то, потому-то и потому-то. В споре рождается истина, если это конечно спор, а не что-либо другое ;)

All the Best! Mage

ComputerMage ()

Re: Re: Re: Re: Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

to ComputerMage :

>А кто будет оптимизировать размер кернела? Или он резиновый?

А оно того стоит при нынешних ресурсах компьютеров ? :)


MrBool ()

Re: Re: Re: Re: Re: Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

>А оно того стоит при нынешних ресурсах компьютеров ? :)

А о PDA или о часах от IBM вы подумали? :) Я про то, что не стоит полагатся на то, что ресурсов навалом, кернел должен быть кернелом а не большой жирной тушей. И откуда вы знаете на каком железе будет исполнятся этот код? Я понимаю, если вас попросил сосед наваять такую-то такую-то прожку, которая делает то-то то-то, и только для него, то-есть никому она больше не нужна (допустим просто запускает xmms/winamp/mpg123 утром, в кач-ве будильника) - то тут вы можете с уверенностью распоряжатся ресурсами. А Linux вещь давольно таки кроссплотформенная, и портируемая как вверх так и ___вниз___. Ядро может крутится и на большом серваке, и на маленькой трешке, и на аппаратном роутере допустим. Надо экономить ресурсы, и не стоит заявлять, что прошли те времена, когда память была дорогой, и мегарерцы на вес золота.

sseREGa ()

Re: Re: Re: Re: Re: Re: Re: Re: Сравнительное исследование дефектов показывает превосходство стека TCP/IP Linux

to sseREGa :

>А о PDA или о часах от IBM вы подумали? :)

А ты посмотрел на количество памяти в этих железяках ? :)

Вот взгляни сюда к примеру Samsung S3C4510/4530:

http://www.onlinux.com.tw/product/prod_vlinux.htm

и сюда :

http://www.armlinux.net/English/solutions/PowerLink_I/PowerLink_I.htm

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

"НЕСОГЛАСЕН !" (C) Всмысле что ресурсы надо экономить
таким образом как это делает Mage :)

MrBool ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.