RFC2414 limits it to min (4*MSS, max (2*MSS, 4380 bytes))
I'll enforce that.
It also has something to say about its interaction with pmtu discovery,
I'll try to look at that.
The concern the original poster raised about the timer lock retry delay much
too long is correct I think, looking from his perspective I think even
the HZ/20 we currently use is too long - do you have any objections to lower
it even more, e.g. to HZ/50 or HZ/100 ?
BTW there is a easy way to lower the socket locking latencies for the
receive path - by unlocking the socket before doing the user copy. Now this
might lose some data in case of EFAULT, but I think that is ok (what does
the user expect when passing a bad pointer anyways?). The same works for
the send path.
What do you think about removing the 200ms clamp in tcp_bound_rto - Eric
made this a FIXME, and when it really hurts Beowulfs perhaps something should
be done about it.
What I think should be done:
- Implement the initial cwnd sysctl with enforced limits.
- Add a no delayed acks sysctl (like NetBSD)
- Add a sysctl that extends quick ack mode to more packets (see recent
discussions on tcp-impl, I think that is often a good alternative to just
turning delacks off)
- Lower the timer lock retry delay even more.
- Think hard about removing the 200ms clamp in tcp_bound_rto, together with
test runs of this change over 28.8 and 64K lines against BSD stacks.
What do you think?
-Andi
-- This is like TV. I don't like TV.- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/