Hi
I have kernel version 2.4.18 and I was looking for a patch to have the
option to disable NAGLE's algorithm.
Is there a patch available for kernels 2.4 and greater and if not, what
other options do I have?
Thanks
Fiona
On Tue, Feb 04, 2003 at 11:39:16AM -0800, Fiona Sou-Yee Wong wrote:
> I have kernel version 2.4.18 and I was looking for a patch to have the
> option to disable NAGLE's algorithm.
> Is there a patch available for kernels 2.4 and greater and if not, what
> other options do I have?
Don't patch the kernel for something like this.
Use setsockopt(TCP_NODELAY) on the TCP/IP socket file descriptors of
your choice.
Read "man tcp".
mark
--
[email protected]/[email protected]/[email protected] __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
On Tue, 4 Feb 2003, Fiona Sou-Yee Wong wrote:
> Hi
>
> I have kernel version 2.4.18 and I was looking for a patch to have the
> option to disable NAGLE's algorithm.
> Is there a patch available for kernels 2.4 and greater and if not, what
> other options do I have?
>
> Thanks
> Fiona
Just turn it off in your program:
int on = 1;
setsockopt(s, SOL_TCP, TCP_NODELAY, &on, sizeof(on));
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.
On Tue, Feb 04, 2003 at 11:39:16AM -0800, Fiona Sou-Yee Wong wrote:
>I have kernel version 2.4.18 and I was looking for a patch to have the
>option to disable NAGLE's algorithm.
>Is there a patch available for kernels 2.4 and greater and if not, what
>other options do I have?
Others already answered this specific question, but I wonder how hard it
would be to create a patch to disable TCP's timeout and retransmit
mechanisms on a given interface? This would allow those of us who have no
alternative other than PPP over ssh for VPN to greatly improve performance.
Over a well behaved connection this works acceptably, but given any delays
or packet loss it is essentially unusable. I know the real answer is using
something other than TCP as the transport layer for the tunnel (IPSEC, IP
over IP, UDP, etc.) but that isn't always possible. So I'd like a way to
treat the ppp interface the VPN tunnel creates as a completely reliable
transport for which normal TCP/IP retransmits and timeouts don't apply.
It'd just bullheadedly go along transmitting data and assuming it was
received -- the underlying TCP transport can take care of making the link
reliable.
Is this even remotely reasonable? If it would cause performance degradation
it'd have to be a config option or never make the kernel at all (Linus may
never accept it regardless I suppose) But ignoring that for a moment, is it
just too hairy to contemplate? I've done a few patches here and there for
Linux in the past, but nothing like this (and nothing involving networking)
so it is far beyond my capability. But if something was cooked up that
works well enough I'd be willing to try polishing it and porting between
kernel versions where necessary.
But I'd take any suggestions for alterations in /proc/sys/net/ipv4/* that
might help the current state of things.
_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail
On 5 February 2003 02:01, Dave Slicer wrote:
> On Tue, Feb 04, 2003 at 11:39:16AM -0800, Fiona Sou-Yee Wong wrote:
> >I have kernel version 2.4.18 and I was looking for a patch to have
> > the option to disable NAGLE's algorithm.
> >Is there a patch available for kernels 2.4 and greater and if not,
> > what other options do I have?
>
> Others already answered this specific question, but I wonder how hard
> it would be to create a patch to disable TCP's timeout and retransmit
> mechanisms on a given interface? This would allow those of us who
> have no alternative other than PPP over ssh for VPN to greatly
> improve performance. Over a well behaved connection this works
> acceptably, but given any delays or packet loss it is essentially
> unusable. I know the real answer is using something other than TCP
> as the transport layer for the tunnel (IPSEC, IP over IP, UDP, etc.)
> but that isn't always possible. So I'd like a way to treat the ppp
> interface the VPN tunnel creates as a completely reliable transport
> for which normal TCP/IP retransmits and timeouts don't apply. It'd
> just bullheadedly go along transmitting data and assuming it was
> received -- the underlying TCP transport can take care of making the
> link reliable.
I want this too ;) For one, it would be a perfect example of using
good existing tools to achieve the goal instead of inventing
something big and new. Also it does not reduce MTU unlike
packet-encapsulation tunnels.
Now it's an imperfect example due to noted TCP over TCP performance
problem ('internal meltdown').
> Is this even remotely reasonable? If it would cause performance
> degradation it'd have to be a config option or never make the kernel
> at all (Linus may never accept it regardless I suppose) But ignoring
> that for a moment, is it just too hairy to contemplate? I've done a
> few patches here and there for Linux in the past, but nothing like
> this (and nothing involving networking) so it is far beyond my
> capability. But if something was cooked up that works well enough
> I'd be willing to try polishing it and porting between kernel
> versions where necessary.
>
> But I'd take any suggestions for alterations in /proc/sys/net/ipv4/*
> that might help the current state of things.
I'm looking there for the first time ever, but it seems you
can twiddle TCP parameters in /proc/sys/net/ipv4/tcp_*
(OTOH I don't see retransmit timeout controls there...
maybe they have another name?)
In order to make them per-iface one needs to have an ability to
override them in /proc/sys/net/ipv4/conf/ethX.
Seems like this is not implemented.
--
vda
On Wed, 2003-02-05 at 08:47, Denis Vlasenko wrote:
> On 5 February 2003 02:01, Dave Slicer wrote:
> > Others already answered this specific question, but I wonder how hard
> > it would be to create a patch to disable TCP's timeout and retransmit
> > mechanisms on a given interface? This would allow those of us who
> > have no alternative other than PPP over ssh for VPN to greatly
> > improve performance. Over a well behaved connection this works
> > acceptably, but given any delays or packet loss it is essentially
> > unusable. I know the real answer is using something other than TCP
> > as the transport layer for the tunnel (IPSEC, IP over IP, UDP, etc.)
> > but that isn't always possible. So I'd like a way to treat the ppp
> > interface the VPN tunnel creates as a completely reliable transport
> > for which normal TCP/IP retransmits and timeouts don't apply. It'd
> > just bullheadedly go along transmitting data and assuming it was
> > received -- the underlying TCP transport can take care of making the
> > link reliable.
>
> I want this too ;) For one, it would be a perfect example of using
> good existing tools to achieve the goal instead of inventing
> something big and new. Also it does not reduce MTU unlike
> packet-encapsulation tunnels.
>
> Now it's an imperfect example due to noted TCP over TCP performance
> problem ('internal meltdown').
I doubt a hack like disabling RTO would make it into the kernel.
However, try enabling F-RTO at both ends (echo 1 >
/proc/sys/net/ipv4/tcp_frto). This should improve things quite a bit.
You need at least linux 2.4.21-pre3, or linux 2.5.x.
MikaL
> would be to create a patch to disable TCP's timeout and retransmit
> mechanisms on a given interface? This would allow those of us who have no
> alternative other than PPP over ssh for VPN to greatly improve performance.
> Over a well behaved connection this works acceptably, but given any delays
> or packet loss it is essentially unusable. I know the real answer is using
> something other than TCP as the transport layer for the tunnel (IPSEC, IP
> over IP, UDP, etc.) but that isn't always possible. So I'd like a way to
> treat the ppp interface the VPN tunnel creates as a completely reliable
> transport for which normal TCP/IP retransmits and timeouts don't apply.
As I see it, this wouldn't help when the TCP retransmits are
originated by a machine other than the VPN routers, because they don't
know about the new reliability characteristics of their transport
medium. So in any network with more than two machines its usefulness
is rather limited. (Or am I missing something?)
Olaf
> > > loss it is essentially unusable. I know the real answer is using
> > > something other than TCP as the transport layer for the tunnel
> > > (IPSEC, IP over IP, UDP, etc.) but that isn't always possible.
> > > So I'd like a way to treat the ppp interface the VPN tunnel
> > > creates as a completely reliable transport for which normal
> > > TCP/IP retransmits and timeouts don't apply. It'd just
> > > bullheadedly go along transmitting data and assuming it was
> > > received -- the underlying TCP transport can take care of making
> > > the link reliable.
> >
> > I want this too ;) For one, it would be a perfect example of using
> > good existing tools to achieve the goal instead of inventing
> > something big and new. Also it does not reduce MTU unlike
> > packet-encapsulation tunnels.
> >
> > Now it's an imperfect example due to noted TCP over TCP performance
> > problem ('internal meltdown').
>
> I doubt a hack like disabling RTO would make it into the kernel.
> However, try enabling F-RTO at both ends (echo 1 >
> /proc/sys/net/ipv4/tcp_frto). This should improve things quite a bit.
>
> You need at least linux 2.4.21-pre3, or linux 2.5.x.
Wow, thanks! I'll look into it! (Found the draft. Google is cool ;)
What is really needed is raising RTO to large fixed value so that TCP
connection times out before RTs are triggered. And it have to be done only
on pppd-over-ssh iface. Am I right that currently kernel TCP options
are global, not per-if?
--
vda