On Mon, 26 May 2008, Ingo Molnar wrote:
>

quoted text
> * Ingo Molnar  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 :-).
> with the proper tcpdump it gave:

quoted text
>

> [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

> 16:15:05.260000 IP europe.distcc > europe.37198: . ack 1 win 0

>

> 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