disabling nagle

disabling nagle

[Fiona Sou-Yee Wong]

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

Re: disabling nagle

[Mark Mielke]

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

-- 
mark@mielke.cc/markm@ncf.ca/markm@nortelnetworks.com __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | 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/

Re: disabling nagle

[Richard B. Johnson]

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.

Re: disabling nagle

[Dave Slicer]

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

Re: disabling nagle

[Denis Vlasenko]

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

Re: disabling nagle

[Mika Liljeberg]

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

Re: disabling nagle

[Olaf Titz]

> 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

Re: disabling nagle

[Denis Vlasenko]

> > > 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