Dnia czwartek, 14 września 2006 11:17, Wojciech Ziniewicz napisał:

06-09-13, Jakub Wartak vnulllists@pcnet.com.pl napisał(a):

...

Dokladnie, a nieszyfrowane PPPoE dla kerneli 2.6.x _powinno_ sie niemal skalowac tak jak zwykly ethernet, jedynie ilosc ifow moze przeszkodzic przy route-cache... Czyli jesli sprzet wyciaga 200kpps to kernel jako taki nie powinien miec problemow z przekroczeniem 170kpps. Ew. mozna robic bonding do switchy zeby troche rozbic irq na kilka rdzeni ( czyli powiedzmy 4 rdzenie i 4 karty gigaeth, 2 na klienckie ( 2x1000 ) + 2 do rdzenia ( 2x1000 ) ) i na sztywno przybindowac eth do CPU + ustawic etherchannel na odpowiedni mac balancing.

kojarzysz jak przybindować konkretne ETH do konkretnego CPU ? bawiłem sie routingiem irq ale kurde jak zroutowałęm irq jednej karty sieciowej na najmniej zawalony CPU to otrzymywalem taki efekt ze po prostu utylizacja wszystkich procków zwiekszala sie o jakieś 20 %..

Napisalem ze to mozna ( gdzies mi smignelo ), ale nie robilbym tego w warunkach produkcyjnych ( podobno bez bindowania sie to lepiej sprawuje - tez tak bylo napisane ). /me nie testowalo.

imho z bondingiem to zbyt duża rzeźba żeby się w coś takiego bawić..

IMHO to jest wlasciwie podejscie.

no a jeśli chodzi o kernela 2.6 - mam przeważnie najnowszą wersję ;) no i niezbyt skomplikowne regułki firewalla . Normalny limit pppoe to jest prawie sztywno 5-6 mbit , pamietam jak testowałęm pppoe + jedna linijka MASQ - i tyle dokladnie wychodzilo. tearz kiedy sprawdzam w sieci (gdzie dla kazedgo klienta jest oddzielny pppX). Zastanawiam się czy obciązenie procka wyynika z klientów ktorych mam na pppoe czy z tych ktorych mam na iptables + layer7 ...

wiesz może jak to zmierzyć ? gdzieś w /proc pewnie pogrzebać albo w kernelu głebiej ..

Wlacz, wylacz i mierz przez vmstat pozycje sy. Co do l7 - to bardzo obciaza tak jak i ippp2p, w 80% przypadkow jakie widywalem to ludzie mieli po kilka tysiecy regul .. no i sie nie skalowalo. Co do tych 5-6mbit to masz cos zle- ja nie obserwowalem takich ograniczen. A generalnie to NTG.