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