FreeBSD router - propustnost
Tomas Podermanski
tpoder at cis.vutbr.cz
Sun Oct 12 15:25:47 CEST 2003
Peter Sedivy - PeSe wrote:
>On Wed, 8 Oct 2003, Ivo Hazmuk wrote:
>
>
>
>>Dobry den,
>>
>>Co prinaselo necekane problemy nebyla fw pravidla (IPFW), ale SNORT. Ten
>>je schopen s ruznou uspesnosti sledovat provoz do 100Mb/s.
>>
>>Cemu by mel clovek venovat pozornost je kernel. IPSec ci IPF vyrazne
>>snizili propustnost systemem o desitky procent.
>>
>>
>>
>chcete povedat, ze je tak zasadny rozdiel medzi IPF a IPFW?
>Ak ano, su na to argumenty, resp. dokumentacia?
>
> PeSe
>
>
>
>
K tomu zaveru jsme dosli praktickym testovanim. Zkouseli jsme vliv
ruznych parametru na prospustnost routeru/bridge ve FreeBSD. Abychom se
bavili o konkretnich cislech, tak v pripade pouhe pritomnosti kodu ipf
(tedy bez jakychkoliv pravidel ve firewallu) byla propustnost routeru s
procesorem PIII snizena z 301Mbps na 213Mbps, coz je nejakych 30%.
Dalsich cca 35% bylo zpusobeno zarazenim kodu IPSEC do kernelu (tedy z
301Mbps na 194Mbps).
Ostatni volby kernelu nemely na vykonnost routeru prilis vyrazny vliv
(jen namatkou kod IPFW -7%, MULTICAST ROUTING +1,5%, POOLING +1,5%,
BRIDGE +1,5%).
Je ovsem treba brat v potaz, ze se jednalo o testy v laboratornim
prostredi s malou smerovaci tabulkou, bez firewallu, generovanou
velikosti paketu 1400B atd. Je nutno ovsem opozornit, ze vykon
smerovace/bridge znacne zavisi rovnez na poctu pravidel firewallu a
velikosti paketu. Zejmena u velikosti paketu jsou posuny vykonu
markantni (1400B -> 301Mbps, 650B -> 300Mbps, 300B -> 293Mbps, 150B ->
190Mbps, 50B -> 80BMbps, 25B -> 42Mbps). Velikost paketu muze byt
dokonce pro router osudna, protoze v takovem pripade dojde vlivem
obsluhy velkeho poctu preruseni k 100% zatizeni CPU a v pripade, ze na
routeru bezi smerovaci demon dojde k absolutni katastrofe.
Dale jsme zkouseli moznosti PCI-X a vliv poctu procesoru na vykon
smerovace. V pripade pouziti PCI-X nebyl problem dosahnout propustnosti
radove 1Gbps. Zde opet nastava problem zatizeni CPU u kratkych paketu.
Ovsem diky kvalitnejsim procesorum (v nasem pripade Xeon 2,4GHz) je
problematicka hranice posunuta mnohem vys. Pouziti vice procesoru na
roueru nema vyrazny vyznam, protoze kod kernelu je obsluhovan stejne
jednim CPU. U FreeBSD 5.1 doslo dokonce po zarazeni kodu SMP ke znacne
degradaci celkoveho vykonu. FreeBSD 5.2 by na tom snad mohlo byt lip.
Co se tyce platforem tak se nekonaly vyrazne rozdily. Zkouseli jsme
FreeBSD, Linux, OpenBSD, NetBSD a vykonnost jednotlivych platforem byla
v teto uloze vice mene stejna.
T. Podermanski
>
>
>> Ivosh Hazmuk
>>
>>--
>>FreeBSD mailing list (users-l at freebsd.cz)
>>http://www.freebsd.cz/listserv/listinfo/users-l
>>
>>
>>
>
>==============================
> Omnia mea mecum porto
>==============================
> Peter Sedivy - PeSe
> ***
> UNIX/BSD/Linux, Networks
> ***
> pese at pese.sk
>==============================
>
>
>
>
More information about the Users-l
mailing list