Ok, 1.3.87 seems to be fine except for the lack of ACK's in some
circumstances (I've posted a small patch to the kernel mailing list: mail
me if you didn't get it).
I think I'll be able to start the _real_ codefreeze again now that those
pesky ppp problems are hopefully fixed. Maybe we really can get it frozen
now.
> I quickly tried the SunOS host and it doesn't seem any slower than the
> Solaris host.
> I do have to say that they *both* seem a *little* bit slower in 1.3.87.
> However, this may just be a fluke due to some other problem with the
> connection.
The 1.3.87 patch does something experimental: it does delay ack's for
"psh" packets, but the delay is shorter than usual (0.1 sec instead of
0.5 sec). That helps the Nagle rule on the other side to coalesce packets
as appropriate if there are more writes soon afterwards, but on the other
hand it might still be noticeable in for a fast typist that expects to
see the characters one by one.
Somebody (Alan?) said that BSD doesn't delay at all for those kinds of
packets, but that might be due to a inflexible delayed ack setup rather
than any real technical reason.
I do think that the delay is appropriate, but it might be better to make
it even lower (0.02 sec instead of 0.1 seconds). That would still catch
immediate back-to-back packets while not showing up in any interactive
use.
So you could try changing the timeouts in tcp_input.c (function
tcp_queue). It looks something like this:
/*
* If psh is set we assume it's an
* interactive session that wants quick
* acks to avoid nagling too much.
*/
int delay = HZ/2;
if (th->psh)
delay = HZ/10;
tcp_send_delayed_ack(sk, delay);
Just change the "delay = HZ/10" to "delay = HZ/50". It might make a
psychological difference..
Alternatively, instead of checking "psh", you might check the length of
the packet and do the "interactive" thing if the length is different
from the mtu. That's probably a better test ("psh" is really rather
broken).
Linus