On 4/4/06, Robert <[EMAIL PROTECTED]> wrote: > > mi-a spus cineva ca altq+hfsc nu suporta mai mult de 1000 de cozi. > eu as vrea sa am 6-7 cozi mari de 6-7 mb cu cate 400-500 de subcozi > de 384kb maxim. > poate suporta atat ?
Raspuns scurt: nu. Raspuns lung: da. Se poate defini in altq_hfsc.h numarul de cozi. Din pacate insa, ele sint tinute intr-un array, ceea ce inseamna o viteza deplorabila a clasificarii pachetelor. In urma cu ceva timp am scris la repezeala un patch care inlocuieste array-ul cu un hash table. Il gasesti la http://night.rdslink.ro/dudu/misc/altq/altq_hfschash.diff. Atentie insa, nu e foarte mult testat. Din cite tin eu minte, nu functioneaza decit daca ai ALTQ atasat unei singure interfete. La un moment dat n-am mai avut nevoie de el si nu mi-am mai batut capul. Pe testele de-atunci a aratat o crestere enorma a vitezei de clasificare, insa tot insuficienta. Celalalt bottleneck provine din parcurgerea liniara a regulilor pf care fac clasificarea. Dupa o conversatie cu Max Laier am decis ca singura solutie este sa fac un packet filter specializat, care sa tina intr-un radix tree toate subneturile pentru care se face shaping, urmind ca in fiecare nod sa existe un pointer catre coada ALTQ corespunzatoare. Insa nici de asta nu m-am apucat, din lipsa de timp. Daca exista doritori, pot incepe in tandem cu cineva sa lucrez la asta. Framework-ul e simplut. Nu e greu deloc de lucrat cu pfil_hooks. Pina acum, insa, ENOTIME. -- If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. ________________________________________________________ To unsubscribe send a mail to [EMAIL PROTECTED]
