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