Re: Send-Q jams.

[root@thelbane.brisnet.org.au (Dancer)]

> >When this is happening, pinging my dialup SLIP host will result in lost
> >packets (about 10 or 20% loss).
> 
> this was my first idea, too: you are loosing packets inside the system.
> Or, more likely: not the packets themselves, but maybe interrupts, flags,
> pointers, or whatever is needed to manage them...
> 
> >This is my net connection in the process of dying. The two TCP connections
> >that have the data in the Send-Queue will never close. When this happens
> >my connection slowly decreases in response, getting slower and slower and
> >slower.
> 
> i had such a situation one time on a PC w/ Ethernet and heavy traffic. The
> Queue fills up and "nobody" feels responsible for these packets, so they
> just hang around. The fault was a minor bug in the Ethernet Card driver,
> but what really helped me out (bug was found Months later!) was putting in
> another type of Card :->

	Well, this is over a 14K4 V32bis/V42/V42bis modem.

> The connection slows down, because there are really too few buffers
> available, so that more and more packets get lost, and with _most_ of
> them, the TCP system realizes the lost, and requests the packet again.
> Maybe you can simply increase the buffer space? (not quite academic
> solution, i know :-)
> 
> Hmmm... new idea: since i had the trouble with _receiving_ on the PC, and
> your _send_ queue fills up: maybe the _other_ side has the real problem,
> and your side is always busy with _repeating_ all the packets?
> 
> timeouts in a TCP system were defined in _former_ times - the values are
> far too long for today's needs, but they are standardized :-( So some of
> the lost packets may be repeated 1 minute later or so ...

Hmm...Well, something I've noticed:

Assume that I do an 'nslookup', and set 'server rockwell.com' (because I want
to see what hosts are in their domain, for example). I then 'ls rockwell.com'
and wait. Okay, it's a slow day, and a couple of minutes waiting yields nothing
so I give it the ^C and forget about it.

I now have a TCP connection with the status LASTACK (LASTACK1?) and 30 bytes
in the send-Q. If it was zero bytes, there is no trouble. The conenction closes
without problems (maybe not immediately, but after a while).

However, in this case there are some bytes still waiting. There is no immediate
effect on system performance. Within a few hours, though, all network responses
are running at only two thirds of the speed. 24 hours later, at half speed, and
there are noticeable pauses in local response. (You're typing and all of a
sudden, you aren't seeing any of your keystrokes on screen. Then after a few
seconds, the system wakes up, and the keystrokes appear. This is NOT through
a socket connection, this is on /dev/console!) Everything continues to get
slower and more packet loss is exhibited between here and my directly connected
host. Looking at the modem lights, a solid stream of input data just suddenly
ceases......looooooong pause....resumes.

Leave it for a couple of days and the system response becomes so awful that it
becomes impossible to type.

Dancer