While we are at it: that would explain the poor PPP throughput if the
TCP end is a Linux system, too! Does IRIX 6 support SACK, perchance?
No it doesn't.
Why is Linux using SACK, anyway?
Stevens refers to it like "yeah, the BSD people implemented it once, but
it didn't work so it was discarded and is now obsolete".
Yeah, so obsolete that an RFC was released last year for it, and also
it is why all ongoing research is being done on SACK and it's usage on
long delay paths. Yeah, you know what you're talking about.
And, you know, if Stevens says so, I'd be tempted to just accept this as
God given and be done with it. What was the reason to add SACK support
to Linux? Almost no system under the sun seems to support it, anyway.
Right?
We fill 8 million or so seats with this code, these days we define
"what is to be supported".
To further clarify your misinformation:
1) SACK does improve performance. The only known deficiency (as
stated here if you were paying attention) in the Linux
implementation right now is that the longer the delay path is the
larger the socket buffer size needs to be to get the maximum
benefit from SACK. Increasing these default limits is what is
under discussion right now, but you can change them yourself using
the sysctl interfaces provided.
2) Go read some papers about SACK and research done upon it. Stevens
is not god, and like the rest of us mere mortals he does make
mistakes. All of the LBL researchers and others working on SACK
(many of them "BSD people") have shown with real solid results that
SACK does improve performance, has Stevens done so in the context
in which you have quoted him? Who discarded SACK? Who has claimed
it obsolete? It simply isn't.
Please check your facts and stop spreading misinformation.
Later,
David S. Miller
davem@dm.cobaltmicro.com
-
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/faq.html