Messages in this thread | | | Date | Sat, 13 Apr 1996 11:48:43 +0300 (EET DST) | From | Linus Torvalds <> | Subject | Re: 1.3.87 and SLOW SLIP/PPP |
| |
On Fri, 12 Apr 1996, Mark E. Levitt wrote: > > It's definitly better. I haven't done anything extensive to test it > other than look at interactive telnet response. It seems to be keeping > up with my typing well enough to use the Solaris hosts again.
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
| |