On Wed, 6 Dec 2000, Florin Andrei wrote:
> Mihai RUSU wrote:
>
> >
> > ma gandeam la optimizarea transferului pe DVB cand mi-a venit urmatoarea
> > idee: daca pot face linux-ul (forta chiar) sa isi modifice putin politica
> > prin care seteaza window-ul la conexiunile tcp in principiu ar trebui sa
> > obtin o viteza sporita pe dvb (upload mai putin si proxy-ul de la DVB nu
> > mai trebuie sa astepte dupa ACK-urile mele).
>
> Aha... Io-te inca unu' care s-a gindit la asa ceva. :-)
>
> Practic, cam tot asta ma batea gindul si pe mine intr-o vreme, cind eram
>strins
> rau de tot pe partea bandwidth-ului. Dupa ceva sapaturi prin kernel, am ajuns
> la concluzia ca este perfect posibil. Scrie si in cartile de retele (alea de
> TCP/IP pentru grupa mare) de faza asta.
> Dar... La mijloc sint mai multe belele.
pai man cred ca nu m-am exprimat bine. de fapt ideea a pornit din alta
parte. pe DVB am si eu ca omu 300-800 Mbits/s. din cate stiu eu exista un
client de windows de la Europe Online (provider de servicii internet prin
DVB) cu care cica te duci la o pagina de a lor unde ai rezervat 700Mb (cam
ciudat de mult) si faci o comanda de download cu un URL. in 2-3 zile
comanda este ready. apoi (pe windows cu soft-ul lor) se poate face
super-download de la ei la viteza aproape maxima (2Mb) chiar si fara
uplink. acum treaba cu fara uplink nu prea o inteleg (nu se poate sa nu
apara erori de transmisie ... sa fie ele solutionate la un nivel mai jos
???). oricum de aici presupun ca datele care vin prin antena ar veni
"foarte curate" (a se citi cu erori minime). atunci linux-ul meu care are
o stiva TCP/IP gandita pentru conexiuni normale (DVB o consider conexiune
speciala) are o limita de window maxim de 32k (-1 parca). la viteza cu
care vin datele pe DVB (si la erorile putine care apar) aceasta limita
superioara de 32k este "cam" mica. ceea ce presupun eu este ca in acest
caz special daca linux-ul ar folosi un window mai mare ar merge mult mai
bine (DVB-ul) pentru ca oricum nu are rost ACK-ul (in sensul ca oricum
aproape nu sunt erori). normal ca totul este un compromis ce merita
testat.
dar inainte de a incerca a se implementa ideea ar trebui verificat cate
retransmisii se cer de catre linux la recpetionarea unui fisier de test
(de lungime relativ mare) prin DVB. in felul acesta imi verific ipoteza ca
"nu prea" sunt erori pe DVB. aici deja ma cam depaseste situatia (tcpdump
dar cum si cu ce optiuni si cum ar trebui interpretata iesirea ... awk
rulz).
daca intradevar nu sunt erori prea multe pe DVB (cand spun erori pe DVB ma
refer la cele care ajung la nivelul TCP in sensul ca posibilele erori de
transmisie ar fi corectate de un protocol aflat la un nivel
inferior... stiu iar ma aberez :)), atunci prin modificarea window-ului
ar trebui sa se obtina viteze apropiate de cele prin care se facea acel
download la comanda (parca era o kestie cu multicast acolo , sau poate ma
aberez din nou).
normal ca window-ul ocupand spatiu precis in TCP header are limita
superioara (din cate scrie prin kernel nu ar trebui sa depaseasca 32767 ca
cica ar fi stive TCP/IP care fac calcule cu int pe 2 octeti, desi window
este un intreg fara semn pe 16 biti deci ar putea avea un 65000 macar).
----------------------------
Mihai RUSU
RoEduNet Network Engineer
"... and what if this is as good as it gets ?"
---
Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
unsubscribe from this list.
