[lkml]   [1996]   [Apr]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

 \ /
  Last update: 2005-03-22 13:37    [W:0.026 / U:7.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site