Messages in this thread |  | | From | "Ulrich Windl" <> | Date | Tue, 16 Apr 1996 08:15:35 +0100 | Subject | Re: 1.3.87 and SLOW SLIP/PPP |
| |
On 13 Apr 96 at 11:48, Linus Torvalds wrote:
> > > 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.
Shouldn't the delay be based on (be inverse proportional to) the interface speed? On high speed networks a short delay will probably do, but if you run SLIP over a 2400 baud modem...
> > 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 Ulrich
|  |