Disabling nagle algorithm

[C K Kashyap]

Hi,
Is setting *net.ipv4.tcp_low_latency to 1 the right way of disabling nagle's
algorithm?*
*Regards,*
*Kashyap*

[Anupam Kapoor]

afaik, it disables tcp-prequeue nothing to do with nagle anyways.
also, doing this might have marginal benefits if anything at all due
to most overhead being specific to context switching than anything
else.

anupam

Hi,
Is setting net.ipv4.tcp_low_latency to 1 the right way of disabling nagle's
algorithm?
Regards,
Kashyap
_______________________________________________
Kernelnewbies mailing list
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

[C K Kashyap]

Post by Anupam Kapoor
afaik, it disables tcp-prequeue nothing to do with nagle anyways.
also, doing this might have marginal benefits if anything at all due
to most overhead being specific to context switching than anything
else.
Thanks Anupam ... can you pleast tell me how I could disable nagle's algo?

At a system level. I've seen a lot of info on socket param on the net.

Regards,
Kashyap

[Anupam Kapoor]

is tcp_nodelay not an option ?

anupam

Post by Anupam Kapoor

Post by Anupam Kapoor
afaik, it disables tcp-prequeue nothing to do with nagle anyways.
also, doing this might have marginal benefits if anything at all due
to most overhead being specific to context switching than anything
else.

Thanks Anupam ... can you pleast tell me how I could disable nagle's algo?
At a system level. I've seen a lot of info on socket param on the net.
Regards,
Kashyap

[C K Kashyap]

Post by Anupam Kapoor
is tcp_nodelay not an option ?

Is this a socket option or is there a system wide setting for tcp_nodelay?


Regards,
Kashyap

[Peter Teoh]

Post by C K Kashyap

Post by Anupam Kapoor
is tcp_nodelay not an option ?

Is this a socket option or is there a system wide setting for tcp_nodelay?

Yes, TCP_NODELAY is a socket option:

Going back to the kernel source:

include/linux/tcp.h:

#define TCP_NODELAY 1 /* Turn off Nagle's algorithm. */

and this:

u8 nonagle : 4,/* Disable Nagle algorithm? */

and looking into the kernel source code:

./fs/ocfs2/cluster/tcp.c:
ret = sock->ops->setsockopt(sock, SOL_TCP, TCP_NODELAY,

./net/rds/tcp.c:
sock->ops->setsockopt(sock, SOL_TCP, TCP_NODELAY, (char __user *)&val,
the above are just two of the examples of how to set TCP_NODELAY in the kernel.

At the userspace level:

http://www.linuxquestions.org/questions/other-*nix-55/how-do-i-disable-the-nagle-algorithm-in-enterprise-linux-3-kernel-ver-2-4-21-4-a-556170/

should be the correct way, except that the poster is attempting to do
it in a kernel that does not support it.

As documented in http://linux.die.net/man/7/tcp, the supported kernel
is 2.5.71 and onwards.

[C K Kashyap]

Post by Peter Teoh
#define TCP_NODELAY 1 /* Turn off Nagle's algorithm. */
u8 nonagle : 4,/* Disable Nagle algorithm? */
ret = sock->ops->setsockopt(sock, SOL_TCP, TCP_NODELAY,
sock->ops->setsockopt(sock, SOL_TCP, TCP_NODELAY, (char __user *)&val,
the above are just two of the examples of how to set TCP_NODELAY in the kernel.
http://www.linuxquestions.org/questions/other-*nix-55/how-do-i-disable-the-nagle-algorithm-in-enterprise-linux-3-kernel-ver-2-4-21-4-a-556170/
should be the correct way, except that the poster is attempting to do
it in a kernel that does not support it.
As documented in http://linux.die.net/man/7/tcp, the supported kernel
is 2.5.71 and onwards.

Okay ... so, the situation I have at hand is that there is this app I
cannot modify. I'd like to see its performance with nagle disabled. Is this
possible?

While at it, is there a way to see the socket options of the socket
descriptors in a running app?

Regards,
Kashyap

[Peter Teoh]

#define TCP_NODELAY             1       /* Turn off Nagle's algorithm. */
      u8      nonagle     : 4,/* Disable Nagle algorithm?             */
       ret = sock->ops->setsockopt(sock, SOL_TCP, TCP_NODELAY,
       sock->ops->setsockopt(sock, SOL_TCP, TCP_NODELAY, (char __user
*)&val,
the above are just two of the examples of how to set TCP_NODELAY in the kernel.
http://www.linuxquestions.org/questions/other-*nix-55/how-do-i-disable-the-nagle-algorithm-in-enterprise-linux-3-kernel-ver-2-4-21-4-a-556170/
should be the correct way, except that the poster is attempting to do
it in a kernel that does not support it.
As documented in http://linux.die.net/man/7/tcp, the supported kernel
is 2.5.71 and onwards.

 Okay ... so, the situation I have at hand is that there is this app I
cannot modify. I'd like to see its performance with nagle disabled. Is this
possible?

as u can see from the above two kernel implementation - each is
implementing the algorithm per-socket level, or connection-level, on
top of TCP, so, yes, u want to do that is possible. but u will need
to write a kernel module, that implement itself as a netfilter module,
specifically just for the port that your application is using, and
setup socket connection of TCP_NODELAY type. not sure if it will
work?

While at it, is there a way to see the socket options of the socket
descriptors in a running app?
Regards,

Yes, i think so, just sniff out the network packet, and identify the
correct bit as according to the header: include/linux/tcp.h:

<snip>
u16 advmss; /* Advertised MSS */
u8 frto_counter; /* Number of new acks after RTO */
u8 nonagle : 4,/* Disable Nagle algorithm? */
thin_lto : 1,/* Use linear timeouts for thin streams */
thin_dupack : 1,/* Fast retransmit on first dupack */
unused : 2;
<snip>

Kashyap

[C K Kashyap]

Post by C K Kashyap
--
Regards,
Peter Teoh

Thank you very much Peter.
Regards,
Kashyap

[Peter Teoh]

frankly it is not wise to disable nagle, and the solution i proposed
(using netfilter extension) is really too tedious - the added overhead
may slow down the processing, even though disabling nagle aims to
improve latencies. but modern network card is so fast, that the
bottleneck is not at the network card side, but more likely in the
network gateway, or router side - so u are definitely not going to see
improvement in spite of all the troubles.

[Anupam Kapoor]

yup, that's what i also think. is it possible that nagle+delayed-ack
is causing the perceived slow-down ?

anupam

Post by Peter Teoh
frankly it is not wise to disable nagle, and the solution i proposed
(using netfilter extension) is really too tedious - the added overhead
may slow down the processing, even though disabling nagle aims to
improve latencies.   but modern network card is so fast, that the
bottleneck is not at the network card side, but more likely in the
network gateway, or router side - so u are definitely not going to see
improvement in spite of all the troubles.
--
Regards,
Peter Teoh

[Mulyadi Santosa]

Post by Anupam Kapoor
yup, that's what i also think. is it possible that nagle+delayed-ack
is causing the perceived slow-down ?

could be, but have you tried to switch and use various congestion
control ? check /proc/sys/net/ipv4/tcp_congestion_control and here are
enabled ones from my distro stock kernel:
$ grep -i cong /boot/config-`uname -r`
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=m
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
CONFIG_DEFAULT_TCP_CONG="cubic"

[Anupam Kapoor]

yet another option would be to setup point-to-point ethernet device
(^^) via tun/tap drivers. you can have a userland program receiving
data from the said device, and then use whatever options you want
there.

anupam

Post by Anupam Kapoor
yup, that's what i also think. is it possible that nagle+delayed-ack
is causing the perceived slow-down ?
anupam

Post by Peter Teoh
frankly it is not wise to disable nagle, and the solution i proposed
(using netfilter extension) is really too tedious - the added overhead
may slow down the processing, even though disabling nagle aims to
improve latencies.   but modern network card is so fast, that the
bottleneck is not at the network card side, but more likely in the
network gateway, or router side - so u are definitely not going to see
improvement in spite of all the troubles.
--
Regards,
Peter Teoh

--
In the beginning was the lambda, and the lambda was with Emacs, and
Emacs was the lambda.