FreeBSD router - propustnost

Dan Lukes dan at obluda.cz
Sun Oct 12 22:21:36 CEST 2003


	Jen pro doplneni ...

Tomas Podermanski wrote:
> velikosti paketu 1400B atd. Je nutno ovsem opozornit, ze vykon 
> smerovace/bridge znacne zavisi rovnez na poctu pravidel firewallu a 


	Tady bych upozornil na tu vlastnost ipfw, ze v typickem pripade pruchod 
paketu pravidly firewallu konci na prvnim pravidlu splnenem.

	Pri pouziti IPFW tedy vykon smerovace zasadne zavisi nejen na celkovem 
poctu pravidel, ale take na jejich poradi a celkove filosofii s jakou 
jsou usporadany. Je opravdu zasadni rozdil, jestli 95% paketu vyresi 
pravidlo prvni nebo jestli je totez pravidlo vyresi az daleko vzadu ...

> 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.

	Neznam konfiguraci testovaci masiny, ale pokud slo o jednoprocesorovou 
desku a procesor s hyperthreadingem, pak je tato degradace naprosto 
nevyhnutelna (a byl bych skepticky k tomu, ze to 5.2 vyresi). Jde o to, 
ze procesor se navenek prezentuje jako procesory dva - a jadro s 
podporou SMP (+HTT) se pak k systemu chova jako skutecne 
dvojprocesorovemu. Jenze on fakticky (z hlediska vykonu) dvojprocesorovy 
neni. System to ale nevi a tak scheduler priradi ulohu obema procesorum. 
V tech pripadech, kdy system potrebuje vyssi vykon pro vykonani nejake 
prioritni ulohy na jednoprocesorovem jadre ostatni ulohy proste cekaji - 
pri teto konfiguraci ale scheduler prideli mene prioritni ulohu na druhy 
procesor, cim fakticky odcerpa vykon procesoru dostupny uloe prvni. A 
vyrazna degradace vykonu je na svete ...

	Klicem je - prepracovat scheduler tak, aby rozlisoval fyzicke procesory 
od virtualnich. A do te doby je lepsi eliminovat na jednoprocesorovych 
systemech SMP. A na fyzicky dvouprocesorovych (virtualne 
ctyrprocesorovych) zkusit elimonovat alespon hyperthreading (ale tam 
nevim jestli to jde a jak).


							Dan





More information about the Users-l mailing list