When I am a) using modem ppp connection and b) downloading a file from a
reasonably fast server so that the incoming connection is saturated,
then attempting to open a new network tcp connection while this is going
on fails quite regularly. The user app gets a ECONNRESET error.
Investigation shows that the kernel opens a tcp socket, moves the
connection to the syn_sent state, and gets a response (delayed because
the incoming traffic has saturated the link). The kernel then reports a
bad segment, drops the connection, and tries again. Eventually the
kernel gives up and returns the error.
This never happens if the link is idle or lightly loaded. Heavy load is
extremely important.
I normally use an old Hayes ESP card for the modem, but I've tried a
normal UART and the same thing happens.
I do not see this in 2.2.18. I didn't see this in 2.2.19pre8 but, going
back, there are bad segments but they are not frequent. In pre10 this
behavior is very noticeable and it continues in pre13.
Is there really a problem or am I having orher problems?
Thanks.
--
Mars
2001-02-19 13:28:16.590 UTC (JD 2451960.061303)
X = -1.468251565, Y = -0.627505988, Z = -0.247957428 (au)
X' = 0.006352326, Y' = -0.010425935, Z' = -0.004953649 (au/d)
On Mon, Feb 19, 2001 at 08:38:43AM -0500, TenThumbs wrote:
> When I am a) using modem ppp connection and b) downloading a file from a
> reasonably fast server so that the incoming connection is saturated,
> then attempting to open a new network tcp connection while this is going
> on fails quite regularly. The user app gets a ECONNRESET error.
>
<snip>
> This never happens if the link is idle or lightly loaded. Heavy load is
> extremely important.
>
I also saw this when my 2.2.19pre12/13 workstation connected to a
2.2.19pre8 isdn-router. When downloading a large file via ftp at max
speed, other connections don't 'get through'.
Perhaps other people can agree/disagree on this?
Jurriaan
--
I never deny, I never contradict. I sometimes forget.
Benjamin Disraeli
GNU/Linux 2.4.1-ac19 SMP/ReiserFS 2x1402 bogomips load av: 0.01 0.06 0.26
> I also saw this when my 2.2.19pre12/13 workstation connected to a
> 2.2.19pre8 isdn-router. When downloading a large file via ftp at max
> speed, other connections don't 'get through'.
Its normal tcp behaviour. Its something called the capture effect. You can
mitigate it to an extent by using less buffers, but the buffer count in question
is at the ISP end for a download, or by using smaller windows
> I also saw this when my 2.2.19pre12/13 workstation
> connected to a
> 2.2.19pre8 isdn-router. When downloading a large
> file via ftp at max
> speed, other connections don't 'get through'.
>
> Perhaps other people can agree/disagree on this?
>
> Jurriaan
FWIW, that happens to me on the stock 2.4.1 too.
Regards,
Michel
____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie
On Tue, 20 Feb 2001, Alan Cox wrote:
>
> Its normal tcp behaviour. Its something called the capture effect. You can
> mitigate it to an extent by using less buffers, but the buffer count in question
> is at the ISP end for a download, or by using smaller windows
>
Some dumb questions.
Does this explain why the kernel sees bad segments? Do you know what
changed between pre8 and pre10 so that I can undo it? Exactly which
windows should be smaller?
Thanks.
--
Pluto
2001-02-21 14:04:40.621 UTC (JD 2451962.086581)
X = -8.608189699, Y = -28.428478747, Z = -6.278034413 (au)
X' = 0.003075244, Y' = -0.001008929, Z' = -0.001241413 (au/d)
> Does this explain why the kernel sees bad segments? Do you know what
> changed between pre8 and pre10 so that I can undo it? Exactly which
> windows should be smaller?
It doesnt explain bad segments.
TCP windows