Am avut problema asta cu un Realtek 8139 parca. Sunt anumite modele )cel putin) care se pare ca au probleme cu bufferele. In sensul ca, la un transfer foarte rapid, dupa cateva secunde (mie la un moment dat mi se intampla chestia dupa fix vreo 45-50 secunde parca) conexiunea ingheata efectiv.In paralel functioneaza orice altceva, ping, eventual chiar alta conexiune, dar aceea este pierduta. Nu am stat prea mult sa-mi explic, dar se pare ca la un burst foarte mare, bufferele placii se umplu si blocheaza transferul efectiv. Treaba e discutabila, oricum, daca ai realtek, de la asta cred ca e. Am observat de asemenea ca nu toate conexiunile diverselor protocoale erau blocate, ci (parca, nu mai stiu exact) http-ul era si ftp nu. La cam aceeasi viteza de transfer.
Pe mine m-a stresat chestia foarte tare. Acum am tot un Realtek 8139 dar care nu mai face problema asta, si probabil e vorba de un subtip al sau, o revizie mai noua ceva... > On Sat, 28 Jun 2003, Bogdan Marinca wrote: > > [EMAIL PROTECTED] bogdan]# ping -s 1492 202.76.147.10 > > PING 202.76.147.10 (202.76.147.10) from 194.176.189.26 : 1492(1520) > > bytes of data. 1500 bytes from 202.76.147.10: icmp_seq=1 ttl=230 > > time=421.426 msec 1500 bytes from 202.76.147.10: icmp_seq=3 ttl=230 > > time=417.304 msec 1500 bytes from 202.76.147.10: icmp_seq=5 ttl=230 > > time=440.965 msec 1500 bytes from 202.76.147.10: icmp_seq=6 ttl=230 > > time=424.697 msec 1500 bytes from 202.76.147.10: icmp_seq=8 ttl=230 > > time=451.531 msec 1500 bytes from 202.76.147.10: icmp_seq=10 > > ttl=230 time=433.467 msec > > > > --- 202.76.147.10 ping statistics --- > > 11 packets transmitted, 6 packets received, 45% packet loss > > round-trip min/avg/max/mdev = 417.304/431.565/451.531/11.860 ms > > [EMAIL PROTECTED] bogdan]# ping -s 1500 202.76.147.10 > > PING 202.76.147.10 (202.76.147.10) from 194.176.189.26 : 1500(1528) > > bytes of data. 1508 bytes from 202.76.147.10: icmp_seq=0 ttl=230 > > time=430.570 msec 1508 bytes from 202.76.147.10: icmp_seq=1 ttl=230 > > time=442.160 msec 1508 bytes from 202.76.147.10: icmp_seq=2 ttl=230 > > time=420.057 msec 1508 bytes from 202.76.147.10: icmp_seq=5 ttl=230 > > time=442.152 msec 1508 bytes from 202.76.147.10: icmp_seq=6 ttl=230 > > time=438.970 msec 1508 bytes from 202.76.147.10: icmp_seq=7 ttl=230 > > time=435.749 msec 1508 bytes from 202.76.147.10: icmp_seq=8 ttl=230 > > time=479.583 msec > > > > --- 202.76.147.10 ping statistics --- > > 10 packets transmitted, 7 packets received, 30% packet loss > > round-trip min/avg/max/mdev = 420.057/441.320/479.583/17.198 ms > > Destul de elocvent nu crezi ? :) > > > Deci ... daca nu a primit FIN sau RESET ... sau astea > > s'au pierdut pe drum ... nu se mai face retry ? > > Daca nu se raspune la retry, nu exista timeout? (sau > > acesta este extrem de mare, nedefinit de mare?) > > > > Merci, > > > > Bogdan > > AFAIK cel care a trimis, dupa ce trimite window size in packete, > asteapta ACK, daca nu primeste intr-un anumit interval face retry > (iar trimite acele packete). Timeout-ul unei conexiuni e foarte mare > cred (7200 secunde ?). Daca tu ai probleme intre tine si cel care iti > trimite packetele, la dimensiuni mari, acestea nu ajung la tine si > deci ala de la distanta tot incearca. > > ---------------------------- > Mihai RUSU > > Disclaimer: Any views or opinions presented within this e-mail are > solely those of the author and do not necessarily represent those of > any company, unless otherwise specifically stated. -- "Let's be realistic and try the impossible." - Che Guevara
