On Tue, 12 Nov 2002 14:44:58 +0200, [EMAIL PROTECTED] said: > > Ar putea fi din cauza parametrului burst care "spune" numarul de bytes pe > >care o clasa ii poate trimite cand ii vine randul la transmis. Daca de ex > >ai burst de 8k si un capac superior de 10k itzi dai seama ca o sa se > >depaseasca aia 10k pentru o pedioada scurta de timp. > > > Ok. Inteleg. O sa refac experimentul cu 0burst ( daca se poate seta, > probabil ca da). > > Acum, o intrebare mai teoretica pentru cei dintre voi care au inteles > exact sau au vazut in practica... > Nu de alta, dar ca sa stiu la ce sa ma astept. > Sa zicem ca am burst 0 si alte setari eventuale care sa limiteze o masina > interna exact la x kbit, lucrez NUMAI > pe interfata spre intern. Atunci, in principiu, ce se intimpla pe > interfata externa daca stiu sigur ca numai > statia limitata face trafic? Cu alte cuvinte, cum influenteaza limitarea > pusa de mine pe interfata interna > traficul care curge intre interfete (in cazul nat) sau traficul generat > de procese gen squid netransparent etc > pe interfata externa (atunci cind requestul de proxiere vine de la statia > limitata de ex)? Ne bazam toti pe > modul de functionare al tcp/ip? cu slow-start etc ? Sau altceva? Cineva > stie sa-mi explice si mie? Sper sa > intelegeti ce ma framinta, daca nu, reformulez :)
vezi ordinea de parcurgere a unui pachet de la http://www.docum.org/stef.coene/qos/kptd/ care cred ca raspunde la intrebarea ta apoi cred ca raspunsul este in mailul meu anterior; Pe scurt/simplu o sa vina repede 100Kbit raspunsul in squid, dar apoi o sa plece lent spre luser. C -- Ciprian Niculescu -- http://fastmail.fm - The professional email service --- Pentru dezabonare, trimiteti mail la [EMAIL PROTECTED] cu subiectul 'unsubscribe rlug'. REGULI, arhive si alte informatii: http://www.lug.ro/mlist/
