Re: 2.2 to 2.4... serious TCP send slowdowns

[Mika Liljeberg <Mika.Liljeberg@welho.com>]

On Tue, 2002-07-23 at 00:13, Hayden Myers wrote: 

> I dumped the other side and it does confirm that the advertised window is
> increasing.  This is may not be the problem.  So if I understand
> correctly 2.4 has window scaling while 2.2 didn't and that's why the
> window advertisement is larger initially in the 2.2 than the 2.4.

The TCP window scaling option is something else. You are correct,
however, that 2.4 manages receiver side buffers differently and
therefore advertises differently. This is designed to save buffer memory
in a HTTP server and should actually be good for your application.

> I 
> still have a theory as to why this smaller window size and/or scaling
is
> slowing us down.
> 
> > 
> > The 6432 you're seeing is the server telling the client how much the
> > client is allowed send. Only, the client isn't sending anything. You
> > need to look at what the client is advertising to the server.
> The client's advertisement seems to increase as the packets keep rolling
> in.

Correct. 

> I just noticed a large number of delayed acks in /proc/net/netstat.  Do
> you think it's possible that a lot of clients have delayed ack and are
> holding up our connections?

Again, don't think so. Unless Alexey has changed something recently,
Linux quickacks every full sized segment immediately during the
slowstart phase. This means that, in the beginning, the congestion
window is growing as fast as the specs allow. 

If in doubt, you can set the TCP_NODELAY option. Just make sure your app
is sending full sized segments if you do this, otherwise it will just
degrade performance. 

Anyway, try posting some hard data. Maybe somebody on these lists can
figure it out.

	MikaL