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

Прав ли я (от наилучшего к худшему)?

1.) BSD (разработали то TCP/IP в Berkly)

2.) Linux

3.) Windows 2000 <<<<< ??

4.) Другие ОСи (OS/2, OS X, Windows 9x, WinXP, etc).

В каком порядке идут другие OS? Из них, есть ли что то круче Win 2k?

Сейчас начнётся... Предвижу очередную "наиболее популярную тему"...

OSX == BSD

Elendal

Berkeley

> Сейчас начнётся... Предвижу очередную "наиболее популярную тему"...

А что, неплохо, я уже какой день по вечерам забавляюсь тем, что читаю про то, какая NTFS крутая в высказываниях Ирси, про то что NTFS с ее потоками нафиг никому не сдалась в высказываниях других ;)

2anonymous (*) (2003-02-14 00:55:09.453)

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

Ставить win2000 на две ступени ниже BSD тоже неправильно. Ее tcp/ip стек во многом срисован с BSD. Причем один в один. То же самое относится и к OS X и WinXP.

И вообще спор на эту тему не имеет смысла. В 21-ом веке все основные игроки на рынке ОС имеют вполне приличную реализацию
tcp/ip. Спорить можно лишь о качестве драйверов сетевых
устройств, о дополнительных возможностях, как то - непревзойденное по гибкости сочетание iptables+iproute2 в линуксе ;)

> я уже какой день по вечерам забавляюсь тем, что читаю про то, какая NTFS крутая в высказываниях Ирси

Ха-ха. Сразу видно, что человек недавно приобщился к местным
форумам. Те, кто постарше узнали все про NTFS еще из
прошлогодней лекции ирси. А еще более страшие - из
позапрошлогодней. А еще более старые.... ну ты понял ;)
Когда мама уронила маленького ирсю, и он долбанулся головкой об
бетонный пол, она сказала: НТФС! С тех пор это и началось.
Есть предложение уронить его еще раз тем же местом и сказать "XFS". Глядишь, и снимется заклинание ;)

Cannot open the HTTP connection to www.reasoning.com port 80; [No route to host]

Интересно, на какой ОС держат сервер сами "исследователи".

Левый какой-то отчет http://www.reasoning.com/downloads/Open_Source_White_Paper.pdf Чем-то напоминает сравнение с "Обычным стиральным порошком"...

Исследователи держут его на Red Hat/Linux

>долбанулся головкой

какая-то у вас, простите, порнография.

>anonymous (*) (2003-02-14 04:06:41.288)

>Cannot open the HTTP connection to www.reasoning.com port 80; [No >route to host

Во дебил. Да, если у тебя роуты криво написаны, то, кому ж быть виноватым, кроме как 'исследователям' и их оси.

Ирси то чего молчит? Спит, поди, еще?

ну дык сюда-то он зашел... так что с роутами у него всё окей.

Дешевая реклама

2anonymous (*) (2003-02-14 04:03:29.464): ха-ха... ты о какой XFS говоришь - об ориганальной или об том кастрированным по самые уши варианте, который живет под leenjux? ;)
Вот здесь http://www.ixbt.com/comm/gig-eth-64bit-amd760.shtml с TCP/IP в leenjux сразу все становится понятным имхо... Прошу заметить что это побочный результат совсем других исследований или шило в мешке не утаишь...:) Как нормальную нагрузку дали, так они и загнулось... Что впрочем вполне ожидаемый результат имхо и о подобных вещах (leenjux хреново живет под большими нагрузками) говорили давно...

2Irsi Вот здесь http://www.ixbt.com/comm/gig-eth-64bit-amd760.shtml с TCP/IP в leenjux сразу все становится понятным имхо... Прошу заметить что это побочный результат совсем других исследований или шило в мешке не утаишь...:) Как нормальную нагрузку дали, так они и загнулось...

А можно узнать по каким графикам Вы такие далеко идущие выводы делаете?

MX

to Irsi :

> (leenjux хреново живет под большими нагрузками) говорили давно...

Расскажи эту сказку IBM :) А если ты жопу с пальцем сравниваешь то
это сугубо твои сексуальные трудности.

Ну ну видел я исходники разбора tcp проткола в Линухе(2.4.6) такого сраного кода в своей жизни до сих пор не встречал, как он работает хрен его поймет, туева хуча функций без названий и понятных заголовков, которые хрен знает что делают. Зато в бзди (4.4) разбор tcp протокола закручен в рдну функцию в 2000 строк с небольшим по моему. Очень красиво написан, правда с безусловными переходами, зато все понятно. И ессестно бсдя заруливает линух. Я не знаю что там в последних версиях ядра линуха наворотили, но мне кажется, что скорость можно увеличить простым упорядочиванием и разбором того дерьма, которое содержит ядро Линуха.

А Вин - вообще не живет ;) Начинает треды между процами шпынять

2MrBool: а IBM это и без меня прекрасно знает и именно потому что leenjux их не держит, он и используется ими на low-end серверах... Для больщих нагрузок у них есть сервера с AIX за отдельные деньги...:)

2anonymous (*) (2003-02-14 10:45:35.93): а вы хоть статью-то прочитали? внимательно?

"функций без названий"? Это хит дня однозначно. ;)

to anonymous (*) (2003-02-14 10:48:43.306) :

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

Ключевые слова "закручен в рдну функцию в 2000 строк" и "красиво написан
правда с безусловными переходами"

:)))) Я могу только сказать, любителей GOTO гнать в шею надо
(невыполнимое желание :) Кроме того уважаемый, у Вас весьма
извращенное понятие о красоте кода ;)

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

Оптимизировать надо алгоритм разбора, упорядочивание ничего не даст
кроме "удобочитаемости".

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

Ирся, там же сравнивались драйверы сетевых карт, а производительность стека TCP/IP

Кстати, а какого фига авторы этого теста сделали окно TCP у Windows в 20 мегов, а у Линуха такой же тюнинг не сделали? Может в этом источник отставания?

>Вот здесь http://www.ixbt.com/comm/gig-eth-64bit-amd760.shtml с TCP/IP в
>leenjux сразу все становится понятным имхо...

2Irsi: Сразу видно, что ты ламер, где в этой статье идет сравнение TCP/IP?
А статьей этого криворучки можно подтереть одно место, так как драйвера
для гигабитных езернетов постоянно совершенствуются, и уж будь уверен,
что сейчас эти драйвера, впрочем как и тогда, делают моздайку на гигабитных
сетях не хуже, чем в мегабитных....

Ну да - онанимусы могут отделеить на подобных тестах где виноват драйвер, а где стек TCP/IP... НУ-НУ...:))))))))) А подумать не пробовали? Впрочем куда вам...:)

Функций без названия?
Closures, что ли? 8)))))

Я думаю Irsi понравится такой тест - http://www-106.ibm.com/developerworks/library/l-rt6/ , в котором идет речь о сокетах, есть исходники программ тестов.

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

Вот Irsi, вроде не дурак, а порой такую муйню несет.
> где виноват драйвер, а где стек TCP/IP... НУ-НУ...:))))))))) А подумать не пробовали?

Что НУ-НУ? Ты название статьи читал?

!!! Тестирование гигабитных сетевых адаптеров на 64-битной шине PCI, платформы AMD760MPX

Где здесь о сравнении стеков? Какая методика тестирования? Что хотели показать авторы теста?
Зачем что-то домысливать? Придумывать?

К тому же домысливать каков стек TCP/IP на новом железе, которое еще и не работает толком... как-то маниакально.

"" В наличии у меня оказалось три драйвера. Два из них &#8212; родные &#8212; Broadcom BCM 5700 with Broadcom NIC extension (NICE) версии 2.028 (от 05/11/2001), с прилагаемого компакт диска и тот же драйвер версии 5.05 (от 24/09/2002), скачанный с сайта. Оба драйвера успешно собрались, но оба не работали на ядре 2.4.20. Версия 5.05 выдавала Segmentation Fault при попытке поднятия адаптера, а версия 2.028 &#8212; Kernel Panic при попытке послать какие-либо данные (например, ping). На предыдущем ядре версии 2.4.19 оба драйвера собрались и работали, но не давали изменять размер MTU (в ответ выдавая Invalid argument). ""

"" Для ОС Linux предлагаются лишь драйвера для ядра 2.2.х. В ядрах версии 2.4.х они не собираются, поэтому использовался встроенный в ОС драйвер &#8220;National Semiconduct DP83820&#8221; версии 0.18 (для ядра 2.4.19) и версии 0.20 (для ядра 2.4.20). Но в ней задан максимальный размер Jumbo Frame &#8212; 8192. Причем не правя исходный код драйвера, невозможно выставить размеры пакета более 1500.

На драйверах версии 0.20 при включении Jumbo-фреймов, в самом начале теста (при размере пакета передаваемых данных больше 1024 байт) адаптер &#8220;зависал&#8221;. То есть ОС продолжала функционировать, но передача и прием данных прекращались, как будто от адаптера отсоединили сетевой кабель. При использовании драйвера версии 0.18 эта ситуация наступала несколько позже, на MTU = 6000 и при размерах данных для передачи больше 128 КБ. На всех остальных адаптерах с микроконтроллером DP83820 ситуация полностью повторялась. ""

"" Последняя версия драйвера (1.2.905.2001) для Windows, скачанная с сайта компании, не заработала. Во время требуемой (после установки драйвера) перезагрузки ОС падала с BSOD (синим экраном смерти). Поэтому в тестах были использованы референсные драйверы (те же, что и адаптера TEG-PCITX2)

Для Linux использовался поставляемый с ядром драйвер &#8220;National Semiconductor DP83820&#8221;, как и у предыдущего адаптера. Драйвер, выложенный на сайте компании, не собирался, а уже собранный (поставляемый в пакете с исходными текстами) модуль не запускался, требуя отсутствующие зависимости. ""

Какое уж тут тестирование!

К тому же для этого не мешало бы написать многоплатформенную (windows/linux) прогу для тестов и уж после этого говорить о сравнении.

>Ну да - онанимусы могут отделеить на подобных тестах где виноват драйвер,
>а где стек TCP/IP... НУ-НУ...:))))))))) А подумать не пробовали? Впрочем
>куда вам...:)

2Irsi: Но ты то как-то в этом тесте увидел TCP/IP стек.....:))))))))))))
Короче, ламо, скорость которую сравнивал криворучка никак не зависит
от стека, просто драйвера имеют низкий трансфер связаных с
реверс-инженирингом большенства из них и что бы выдержать стабильность.
Когда начнешь писать драйвера, вот тогда мы с тобой и поговорим на эту
тему...

Нда... это уже даже не смешно - это клиника...:( Бля, забейте хуй на название статьи и посмотрите на методику тестирования! Ибо на сарае хуй написано, а там дрова лежат... :)
Потом попробуйте подумать - тогда может разговор и получится....

>:)))) Я могу только сказать, любителей GOTO гнать в шею надо >(невыполнимое желание :) Кроме того уважаемый, у Вас весьма >извращенное понятие о красоте кода ;)

когда нет возможности пользоваться исключениями ничего лучше goto не придумаешь. Не зря во многих функциях ядра Linux есть по две метки error: и quit:

Цитата с developerWorks: The results show that Red Hat 7.2 provides a significantly faster socket implementation. Using the coding techniques demonstrated here, Linux achieved a 2.5 times faster transfer rate than either of the Windows platforms.

to Irsi :

>а IBM это и без меня прекрасно знает и именно потому что
>leenjux их не держит, он и используется ими на low-end
>серверах... Для больщих нагрузок у них есть сервера с AIX
>за отдельные деньги...

"Linux will replace AIX"

http://news.zdnet.co.uk/story/0,,t269-s2129537,00.html

Может перестанешь глупости говорить ?

У Irsi (*) (2003-02-14 14:07:23.641) кончились аргументы... и начался мат :)

to anonymous (*) (2003-02-14 14:07:56.528) :

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

:) Ну да, это если не думать.

2MrBool: а может прочитаем статью до конца и перестанем выдирать отдельные фразы из контекста? :) Тогда сразу станет понятно когда конкретно replased - когда рак на горе свистнет...:)

to Irsi :

>а может прочитаем статью до конца и перестанем выдирать >отдельные фразы из контекста?

"The road map is clear. It's an eight-lane highway."

:)

>Тогда сразу станет понятно когда конкретно replased
>- когда рак на горе свистнет...

Т.е ты признаешь сам факт замены AIX на Linux ? :))

Ирси где ты брал такую классную шмаль? :)))

2MrBool: при сроках определенных как "когда рак на горе свистнет" - одназначно признаю. :))

2ttyS0: есть одно место... на Белорусской... а что? ;)

Только идиоты могут орать что линукс не держит нагрузки.У меня CP-1 кластеры на линукс поменяли спарки и почему то не дохнут.Что я сделал не так?

to Irsi :

>при сроках определенных как "когда рак на горе свистнет"
>- одназначно признаю

Ну вот и прекрасно, так и запишем : Irsi однозначно признал
что Linux имеет потенциал для того что бы заменить AIX на
hi-end серверах :)

Кстати, а на чем там макросаксовское поделие бегает, ась ? :)

2MrBool: нет, так не согласен - без определения сроков такое заявление некорректно. Делать такие заявления без указания сроков нельзя - это просто непрофесионально, и не надо мне приписывать то, чего я никогда не делаю. :)

А какая в жопу разница? на Unisys ES7000 например... у leenjux при виде таких тачек пупок развязывается...:)

Я недавна вплотную столкнулся с реализацией стека TCP/IP на FreeBSD и Windows 2000. Кому интересна кроссплатформенная тулза для проверки пропускной способности канала - имя ей iperf. Но тестирование ей канала между виндой и фрей сопряжено с определенными ньюансами ;-) На сколько я понял, iperf не очень аккуратно работает с параметрами TCP. В процессе поиска по инту натолкнулся на пару интересных статей, надеюсь, что они пригодятся еще кому-нибудь.

http://www.psc.edu/networking/perf_tune.html

http://rdweb.cns.vt.edu/public/notes/win2k-tcpip.htm

прошу прощения за опечатки

2MrBool >:)))) Я могу только сказать, любителей GOTO гнать в шею надо

Взято с сайта Ричарда Стивенса (говорит Вам о чем-нибудь это имя?) http://www.kohala.com/start/rstevensfaq.html

Q: Why do your programs contain gotos? Read Structured Programming with go to Statements by Knuth in the ACM Computing Surveys, Vol. 6, No. 4, Dec. 1974 issue. (In fact, this entire issue of Computing Surveys is a classic.) My challenge to the goto-less programmer is to recode tcp_input() (Chapters 27 and 28 of TCP/IPIv2) without any gotos ... without any loss of efficiency (there has to be a catch).

Поиск в google по точной фразе "Structured Programming with go to Statements" показывает, что таки да, и Дональд Кнут (а это имя Вам известно?) не признает безусловно вредным использование обсуждаемой конструкции... Ну как, Кнута тоже в шею будем гнать? :)))

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

Юрий Фролов

Как развяжется так и завяжется Если есть Unisys ES7000 значит и там будет линюх. Он идет семимильными шагами. Никогда одна коммерческая компания(пусть даже и гигант) не сможет тягаться с ОС в которую вкладывается труд сотен тысяч девелоперов по всему миру. Просто мелкосакс спасает фора по времени и по рынку, но это будет недолго. Каков был взгляд мелкосакса на линукс и опенсорсе? 1.дешевая поделка 2.опасный вирус 3.конкретный конкурент ...а что будет дальше?

>А какая в жопу разница? на Unisys ES7000 например...

Именно батенька, M$ поделки дальше intel arch не уехали :)

Где бегает linux рассказывать ?

>у leenjux при виде таких тачек пупок развязывается...:)

А на zSeries у windoze пупок не развяжется ? :) Linux кстати
там бегает :)

to Юрий Фролов :

Это все в теории хорошо, но вот за использование goto РЕАЛЬНО
выгоняют в шею :) Что же касается генераторов кода :
ты когда-нибудть такой код сопровождал ? Это код для
компайлера а не для человека и применение таких тулзов
огранничено.

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