ce"), pe interfata externa am doar un TBF amarat sa nu suprasolicitBun, dar in conditiile astea intelegi ca nu controlezi upstreamul prietenilor tai, da? Si asta ar putea avea niscaiva efecte secundare asupra conexiunilor TCP. De ex. foloseam pina nu de mult departajarea clara pe clase atit pe in cit si pe out (cu aceleasi filtre, desigur cu dst si src inversate). Problema aparea cind ajungeam la "blana", adica cu upstreamul (sau downstreamul) la maxim. Atunci downstream-ul (sau upstreamul) era pe la un sfert de capacitate. De ce? Pt ca pachetele TCP cu ACK erau intirziate de SFQ si asta avea ca efect incetinirea vitezei respectivei conexiuni TCP. Solutia pt mine a fost sa creez o clasutza mica ca rata da' medie ca ceil in care sa bag toate pachetele cu ACK cu size mai mic de 64 octeti.
Povestea mea nu te ajuta cu mare lucru; a fost data doar ca exemplu. Pe scurt, daca folosesti ca rate pt 1:0 latimea de banda a device-ului tau (recte modemul), atunci poti sa te astepti la ciudatenii din astea pt ca nu tu vei controla latimea de banda ci modemul tau impreuna cu perechea de la provider. Coada se formeaza acolo unde e botleneck-ul of course. Sa zicem ca cineva porneste un download care va fi de 100kbit pt ca nimeni nu foloseste device-ul. Daca pe modem nu ai si ceva extra, atunci conexiunea care a inceput la 100kbit va scade putin in timp ce conexiunea noua va lua felia lasata de modem.
Iti propun sa faci urmatorul test. Scade rate-ul si ceil-ul fiecarei clase la jumatate si vezi daca iti merge asa. Asta bineinteles insotita de r2q 1 si/sau quantum la clasele mai mici de 12kbit. Daca totul merge ca uns (cu impartire de trafic si alte alea) atunci problema ta este aceea a supraestimarii rate-ului.
--
Pentru dezabonare, trimiteti mail la [EMAIL PROTECTED] cu subiectul 'unsubscribe rlug'.
REGULI, arhive si alte informatii: http://www.lug.ro/mlist/
