On Mon, 30 Nov 2009, Frederic Leroy wrote:

Le Sat, 28 Nov 2009 13:31:14 +0200 (EET),
"Ilpo Järvinen" [off-list ref] a écrit :

quoted

On Sat, 28 Nov 2009, Frederic Leroy wrote:

quoted

Le Sat, 28 Nov 2009 00:12:23 +0200 (EET),
"Ilpo Järvinen" [off-list ref] a écrit :

quoted

On Fri, 27 Nov 2009, Frederic Leroy wrote:

quoted

I put traces of stall here : 
http://www.starox.org/pub/scp_stall/

[...]
Perhaps having the /proc/net/tcp would at least tell what state the
timer is (if I cannot reproduce right away). ...It is rather strange
that two independent mechanisms for loss recovery seem both to fail
to get triggered here, no traces of retransmission whatsoever. I
think it is for now enough to concentrate on what happens on
192.168.1.15 (=houba?) and get tcpdump and proc/net/tcp from there,
the other end/direction has very little significance here (except for
the fact that bidirectionality might be needed to actually trigger
it). You could even think of getting proc/net/tcp a bit more often,
right from the start:

while [ : ]; do grep ":0016" /proc/net/tcp; sleep 0.1; done | tee
scp_stall-houba.x.proc_net_tcp

...Please wait at least 2 minutes before hitting ctrl-c or otherwise 
artificially intervening.

You're right, 192.168.1.15 is houba.
The faulty behaviour comes back today, I did new captures on
192.168.1.15 only : 
http://www.starox.org/pub/scp_stall/scp_stall-houba.2.pcap
http://www.starox.org/pub/scp_stall/scp_stall-houba.2.proc_net_tcp
http://www.starox.org/pub/scp_stall/scp_stall-houba.3.pcap
http://www.starox.org/pub/scp_stall/scp_stall-houba.3.proc_net_tcp

Thanks, I'll take a look.

Which tool do you use to analyze /proc/net/tcp ?

I just recall the order of fields from net/ipv4/tcp_ipv4.c and apply my 
knowledge about TCP internals from there on. ...I've no particularly fancy 
tools for the job.

-- 
 i.