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

> 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

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


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