On Mon, 26 May 2008, Ingo Molnar wrote:

quoted text
> 
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> > i also ran this for 15 minutes:
> > 
> >   [root@europe ~]# tcpdump src and dst 10.0.1.15 -n
> >   tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> >   listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
> > 
> > but there was no output at all - i.e. TCP has not attempted to do 
> > anything to these connections.
> 
> ... which is not surprising as it traced eth0 ;-) [10.0.1.15 is the IP 
> of the box and routes back to loopback]

Thanks, it's much easier to diagnose right with symptoms that are based
on reality :-).

quoted text
> with the proper tcpdump it gave:
> 
> [root@europe ~]# tcpdump -i lo
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes
> 16:15:05.260000 IP europe.37198 > europe.distcc: . ack 2022529163 win 257 <nop,nop,timestamp 209526 197526>
> 16:15:05.260000 IP europe.distcc > europe.37198: . ack 1 win 0 <nop,nop,timestamp 209526 7020>
> 
> hm, a window of 257 and zero, is that right?

...Yes, though that 257 is lacks the effect of window scaling (and it's 
mostly irrelevant anyway since the problem occurs in opposite dir). The 
sender is using just window probes (/proc/net/tcp shows that too), that's 
why you see them occassionally. So the main problem seems to be that 
receiver doesn't read, rest is just a consequence of that (from TCP POV). 
I doubt that tcp_frto will affect to that (and I read what a stale 
retrans_stamp could do, it would hard cause any troubles, and those minor 
things wouldn't realize in your setup anyway).

I'll take a look into pre -rc1 changes now but it may well be beoynd
what I'm able to figure out.

-- 
 i.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html