Solaris «Nevada», Build 15

> Начнем с того, что в 2.4.3 появились патчи. В том же 2001 году на linux summit был
> представлен NAPI. В FreeBSD тогда об этом и не думали...

А ты собственно имеешь хоть какое-то понятие о том, о чём думали тогда во FreeBSD? Может ты luigi, а мы и не заметили. Cтыдно вылезать с таким знанием. Экспериментальные патчи для device polling пробегали ещё во времена 3.x. Так же как и zero-copy receive для хакнутого firmware TigonII. Всё это используется в продукте, который построен на FreeBSD 3.5 и который мы до сих пор подерживаем.

> FreeBSD обладает худшей по сравнению с Linux сетевой производительностью. Это
> факт, ссылки ищи в указанном архиве.
Тебе подсказать архив со строго обратными фактами? Или сам догадаешься какой?

>> Начнем с того, что в 2.4.3 появились патчи. В том же 2001 году на linux summit был
>> представлен NAPI. В FreeBSD тогда об этом и не думали...

А ты собственно имеешь хоть какое-то понятие о том, о чём думали тогда во FreeBSD? Может ты luigi, а мы и не заметили. Cтыдно вылезать с таким знанием. Экспериментальные патчи для device polling пробегали ещё во времена 3.x. Так же как и zero-copy receive для хакнутого firmware TigonII. Всё это используется в продукте, который построен на FreeBSD 3.5 и который мы до сих пор подерживаем.


Хех, я понятия не имею, что за продукт вы используете, но я точно знаю, что реализация FreeBSD появилась
1. После реализации в Linux
2. После обсуждения ее плюсов и минусов и линуксоидов

На это неоднократно ссылаются - Linux был первым, это факт.

> FreeBSD обладает худшей по сравнению с Linux сетевой производительностью. Это
> факт, ссылки ищи в указанном архиве.
Тебе подсказать архив со строго обратными фактами? Или сам догадаешься какой?

Мда...
FreeBSD представила свой миллион пакетов в прошлом году (или в этом? - запямотовал).
В linux-netdev в этом году (после (!) анонса FreeBSD) были проведены некоторые исследования, настройки и новые тесты - и Linux на такой же конфигурации обогнал FreeBSD (признаюсь - обогнал не на много, но все же обогнал :) ).

Это просто факт, с ним нельзя ни спорить, ни опровергать.

Когда FreeBSD проведет повторные исследования, в которых она окажется быстрее - только тогда твои высказывания будут иметь хоть какой-то вес, пока же FreeBSD на втором месте.

> Это просто факт, с ним нельзя ни спорить, ни опровергать.
Этот "просто факт" идёт лесом, учитывая источник. Ничего другого в linux-netdev написать и не могли. Cоответственно и призывы исполниться чистой веры и хавать тухленькую истину в последней инстанции выглядят туповато. LOR, однако.

> Когда FreeBSD проведет повторные исследования, в которых она окажется быстрее -
> только тогда твои высказывания будут иметь хоть какой-то вес, пока же FreeBSD на
> втором месте.
C весом тобой произнесённых слов похоже ситуация заметно похуже В рассылке пробегала информация о 1.3Mpps на Opteron и о < 1Mpps для Xeon, причём автор тактично умолчал о частоте своего процессора от Intel, да и на сколько конкретно линукс сливал _на момент опубликования новости_ тоже предпочёл не распространяться. Не обязательно со злым умыслом, откуда ж ему было знать, что некоторые тут же попытаются вывести его слова золотыми буковками на иконах и начнут бить лбом в исступлении.

Guess didnt take too long for those BSDers to post on slashdot.
It would be nice for someone to install freebsd and verify the claims
on the routing aspect.
Anyone in Ottawa with BSD expertise drop me a note - I have access to
measurement equipment (and really dont wanna touch BSD if i can avoid it).

cheers,
jamal

PS: We can certainly do better than that on Opterons. Robert
reports a 1.3 Mpps rate on a dual opteron 1.6Ghz. Our numbers on Xeons
are less than 1Mpps. But we can let an old OS like BSD beat us, can we
now ? ;->

Прочтите и оцените высокий штиль. Потом попытайтесь ещё раз протащить тезис о непредвзятости linux-dev.

>Хех, я понятия не имею, что за продукт вы используете, но я точно знаю, >что реализация FreeBSD появилась >1. После реализации в Linux >2. После обсуждения ее плюсов и минусов и линуксоидов

А что ты куришь? Тебе на этот раз туфту впарили! BSD уже лет эдак 35.

>> Это просто факт, с ним нельзя ни спорить, ни опровергать.
>Этот "просто факт" идёт лесом, учитывая источник. Ничего другого в linux-netdev написать и не могли. Cоответственно и призывы исполниться чистой веры и хавать тухленькую истину в последней инстанции выглядят туповато. LOR, однако.


Эвона, как фрюшники обижаются %)
Впрочем, от фанатиков ничего другого и не ожидалось.

Для таких все равно не существует другой истины, кроме своей...

Сообщения от FreeBSD разработчиков принимаются на веру, от Linux - нет.
Диагноз очевиден.

>> Когда FreeBSD проведет повторные исследования, в которых она окажется быстрее -
>> только тогда твои высказывания будут иметь хоть какой-то вес, пока же FreeBSD на
> втором месте.
>C весом тобой произнесённых слов похоже ситуация заметно похуже В рассылке пробегала информация о 1.3Mpps на Opteron и о < 1Mpps для Xeon, причём автор тактично умолчал о частоте своего процессора от Intel, да и на сколько конкретно линукс сливал _на момент опубликования новости_ тоже предпочёл не распространяться. Не обязательно со злым умыслом, откуда ж ему было знать, что некоторые тут же попытаются вывести его слова золотыми буковками на иконах и начнут бить лбом в исступлении.


Ой, да не расстраивайся ты так ;)
Парой писем раньше указана конфигурация - автор Robert Olsson.

Что мы видим: тест на примерно такой же машине (согласен, эта лучше, быстрее и т.п. но ведь не в 1.3 раза? %)) ).
Кстати, что-то фрюшники не показали SMP конфигурации, ну да ладно, SMP результат от Linux вообще выше всяких похвал!

Никто не спорит, что когда фрюшники провели свой тест, линукс был слабее. Но есть одно но.
Фрюшники всех обманули:
1. их карта была на CSA, Linux на pci(x?)
2. у них был специальным образом подправленный драйвер, после добавления такой же фичи в Linux драйвер для e1000, FreeBSD стала отставать, причем заметь, FreeBSD на CSA(!), Linux всего лишь на PCIX.

>Guess didnt take too long for those BSDers to post on slashdot.
It would be nice for someone to install freebsd and verify the claims
on the routing aspect.
Anyone in Ottawa with BSD expertise drop me a note - I have access to
measurement equipment (and really dont wanna touch BSD if i can avoid it).

>cheers,
>jamal

>PS: We can certainly do better than that on Opterons. Robert
reports a 1.3 Mpps rate on a dual opteron 1.6Ghz. Our numbers on Xeons
are less than 1Mpps. But we can let an old OS like BSD beat us, can we
now ? ;->

>Прочтите и оцените высокий штиль. Потом попытайтесь ещё раз протащить тезис о непредвзятости linux-dev.


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

Кстати, Джамал ошибся в конфигурации.

>>Хех, я понятия не имею, что за продукт вы используете, но я точно знаю, >что реализация FreeBSD появилась >1. После реализации в Linux >2. После обсуждения ее плюсов и минусов и линуксоидов

> что ты куришь? Тебе на этот раз туфту впарили! BSD уже лет эдак 35.

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

> Тебе подсказать архив со строго обратными фактами?

LOL indeed. Vot tol'ko rekordy skorosti po internet2 beret pochemu-to NetBSD 3.99.x ...

> Эвона, как фрюшники обижаются %)

bylo by na kogo...
'ts just a flame site [c] orb, #NetBSD (iirc)

releng_5# cat /etc/sysctl.conf
#  This file is read when going to multi-user and its contents piped thru
#  ``sysctl'' to adjust kernel values.  ``man 5 sysctl.conf'' for details.
kern.maxfiles=16384
kern.polling.enable=1
#hw.nv_pollinterval=1000
#kern.random.sys.harvest.ethernet=0     # should be fixed in 5.4
#kern.random.sys.harvest.interrupt=0    # should be fixed in 5.4
#net.inet.tcp.delayed_ack=0             # instant reply, good for speed, but can stop a DOS attack when on
net.inet.tcp.sendspace=131072           # more buffers, good for severs
net.inet.tcp.recvspace=131072           # default was 64*1024
net.isr.enable=1                        # enable direct dispatch, a speedup
kern.ipc.maxsockbuf=524288              # must be a multiple larger than net.inet.tcp, defualt was 4x
kern.ipc.somaxconn=2048
#vfs.read_max=32                        # good speed up in read speeds, you can also increase the buffers for an additional small benefit but at a risk!

#Increasing MAXPHYS in sys/param.h from 128k to 1M increased sequential
#read thruput on my MegaRAID 1600 from 100MB/s to 190MB/s measured on 5.4