Debian - zpomalovani scp
Pavel Kankovsky
peak na argo.troja.mff.cuni.cz
Středa Červenec 30 23:12:35 CEST 2003
On Mon, 28 Jul 2003, Jan Ptacek wrote:
> 1. Pri kopirovani vetsiho souboru (pro testovani pouzivam soubor o
> velikosti cca 40MB) z nebo na debian dochazi ke zpomaleni prenosu. Jako
Obecna rada: doporucuji vyzkouset testovaci program, ktery jen prenasi
data po siti a vubec nepracuje s filesystemem, ani neprovadi nejake dalsi
komplikovane veci.
> klienta jsem zkousel RedHat7.2 a QNX6.2.1 (karty rovnez 3c905), priznaky
> jsou vzdy stejne. Zacne se kopirovat na bezne rychlosti (cca 5-6MB/s),
> priblizne v polovine se vsak prenos skoro zastavi, par sekund roste
> progress bar po jednotlivych procentech, a pak zase vse bezi jak ma. Ve
> vystupu z tcpdump se behem toho zpomaleni vyskytuji serie nekolika ACK
> paketu po sobe, napr.:
>
> 14:30:48.437460 redhat.1056 > debian.ssh: . 28203279:28204727(1448) ack
> 18608 win 8832 <nop,nop,timestamp 309293 852930> (DF) [tos 0x8]
> >>>>>>
> 14:30:48.476874 debian.ssh > redhat.1056: . ack 28204727 win 0
> <nop,nop,timestamp 852934 309293> (DF) [tos 0x8]
> 14:30:48.635125 debian.ssh > redhat.1056: . ack 28204727 win 15928
> <nop,nop,timestamp 852949 309293> (DF) [tos 0x8]
Tady ten debian nastavi velikost okna na 0 (win 0) a tim rika, ze se mu
nejakou chvili nema nic posilat. Cili se zda, ze to zdrzuje ten Debian,
ale tezko rict, proc. Mozna se mu ucpou buffery a musi chvilku cekat...
mozna nez se vysypou na disk? Nebo to souvisi s nize zminenou hypotezou
vymeny klicu?
> 14:30:48.676711 debian.ssh > redhat.1056: . ack 28213959 win 6696
> <nop,nop,timestamp 852954 309313> (DF) [tos 0x8]
> 14:30:48.848004 debian.ssh > redhat.1056: . ack 28213959 win 20272
> <nop,nop,timestamp 852971 309313> (DF) [tos 0x8]
> 14:30:49.338519 debian.ssh > redhat.1056: . ack 28213959 win 50680
> <nop,nop,timestamp 853020 309313> (DF) [tos 0x8]
To je na prvni pohled divne, ale lisi se to zvetsovanim okna,
takze jsou ta potvrzeni asi zpusobovana tim, jak proces ctouci ze
socketu postupne vyprazdnuje jaderne buffery (viz cleanup_rbuf
v tcp.c).
> 14:30:49.354830 debian.ssh > redhat.1056: P 18608:18656(48) ack 28213959
> win 50680 <nop,nop,timestamp 853021 309313> (DF) [tos 0x8]
Tady posila debian nejaka data. Ze by vysilajici (redhat) na ty data
cekal? Ale proc? Ze by vymena sifrovacich klicu?
> 2. Pri kopirovani z Windows (98 i XP, opet karty 3c905) pomoci pscp bezi
> cely prenos pomalu, cca 80-100kB. Kousek z tcpdump vypada takto:
>
> 15:22:27.279560 winxp.3023 > debian.ssh: P 587601:589061(1460) ack 11208
> win 63628 (DF)
> 15:22:27.279574 debian.ssh > winxp.3023: . ack 589061 win 62780 (DF) [tos
> 0x8]
> 15:22:27.279561 winxp.3023 > debian.ssh: P 589061:589293(232) ack 11208
> win 63628 (DF)
Ten pocitac, co to odposlouchaval, ma nejake divne hodiny:
27.279560, 27.279574, 27.279561...to neni moc monotonni posloupnost!
> 15:22:27.279701 winxp.3023 > debian.ssh: P 589293:589345(52) ack 11208 win
> 63628 (DF)
Nevim, nevim, ty wokna jsou nejaky divny. Jaky to ma smysl poslat jeden
velky paket, pak jeden maly a pak jeste jeden uplne prtavy? A vsechny maji
P (push). Hmm...ze by ten wokenni klient vypnul Nagleuv algoritmus?
> 15:22:27.280855 winxp.3023 > debian.ssh: P 590985:591037(52) ack 11208 win
> 63628 (DF)
> 15:22:27.317179 debian.ssh > winxp.3023: . ack 591037 win 62780 (DF) [tos
> 0x8]
Nektera potvrzeni od debianu jsou trochu opozdena, ale to je jen tezko
duvod, proc by mela wokna prestat vysilat, kdyz zdaleka jeste nevycerpaly
kapacitu okna. Hmmm...
> Prenosy Windows->RedHat, QNX->RedHat, RedHat->QNX funguji normalne.
To muze mit ruzne priciny: nejaky detail v RH jadre, trochu jina sitovka,
jiny sitovy kabel...
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."
Další informace o konferenci Linux