Re: _Very_ strange network delay over dialup-ISDN in 2.2.11.

Marc Mutz (Marc@Mutz.com)
Tue, 14 Sep 1999 22:27:39 +0000

David Woodhouse wrote:
>
<snip>
>
> This sounds familiar. I had a similar problem a few months ago. There were
> always a constant number of packets in the outgoing queue. If I ran tcpdump on
> the ISDN interface, I could see them being sent out. TCP connections would
> stall, unless I ran ping across the link to keep the queue moving. ping -f
> would make packets go out almost immediately (chronologically speaking).
>
> I didn't ever manage to find out the cause of the problem. It used to take
> some days of connectivity before it would happen, so I couldn't easily debug
> it. Eventually we installed a leased line to replace the ISDN, so I have no
> clue if it's still happening.
>
> I was using the CVS ISDN code at the time - the standard code wouldn't work
> with the Teles 16.3c IIRC.
>

I just fell over this problem again, this time in 2.2.12. Haven't had it
for two weeks or so, but I must admit that I don't run ping continuously
anymore to keep the link up. Instead, I do the following loop:

while netstat -n | grep tcp | grep -v 127.0.0; do
ping -c 5 $PEER_IP
sleep 4
done

This has revealed some other aspect of the problem, although I guess
they are *but differnt manifestations:

- ping times over an otherwise unused link go from 40ms to 1040ms, ie.
up by exactly one second, the ping interval.
- the above loop almost always shows many connections of the from
tcp 1 0 ... CLOSE_WAIT
that won't go away for minutes. ping -f will not flush these! Example
real-world output follows:
tcp 1 0 129.70.37.20:2143 129.70.4.50:8080
CLOSE_WAIT
tcp 1 0 129.70.37.20:2142 129.70.4.50:8080
CLOSE_WAIT
tcp 1 0 129.70.37.20:2141 129.70.4.50:8080
CLOSE_WAIT
tcp 1 0 129.70.37.20:2140 129.70.4.50:8080
CLOSE_WAIT
tcp 1 0 129.70.37.20:2139 129.70.4.50:8080
CLOSE_WAIT
tcp 1 0 129.70.37.20:2138 129.70.4.50:8080
CLOSE_WAIT
tcp 1 0 129.70.37.20:2137 129.70.4.50:8080
CLOSE_WAIT
tcp 1 0 129.70.37.20:2136 129.70.4.50:8080
CLOSE_WAIT
tcp 0 1 129.70.37.20:2132 128.32.18.166:80
SYN_SENT

So this indicates that the same problem as described by David is present
here, with a queue length of one.

-- 
Marc Mutz <Marc@Mutz.com>                    http://marc.mutz.com/
University of Bielefeld, Dep. of Mathematics / Dep. of Physics


PGP-keyID's:   0xd46ce9ab (RSA), 0x7ae55b9e (DSS/DH)




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/