Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #171941 > unrolled thread

Is nagle disabled?

Back to article view | Back to linux.debian.user

Contents

  Is nagle disabled? Rob van der Putten <rob@sput.nl> - 2016-09-09 16:00 +0200
    Re: Is nagle disabled? Stefan Monnier <monnier@iro.umontreal.ca> - 2016-09-09 18:30 +0200
      Re: Is nagle disabled? Rob van der Putten <rob@sput.nl> - 2016-09-09 20:00 +0200
        Re: Is nagle disabled? Rob van der Putten <rob@sput.nl> - 2016-09-10 13:30 +0200
          Re: Is nagle disabled? Nicolas George <george@nsup.org> - 2016-09-10 13:40 +0200
            Re: Is nagle disabled? Rob van der Putten <rob@sput.nl> - 2016-09-10 14:00 +0200
              Re: Is nagle disabled? Nicolas George <george@nsup.org> - 2016-09-10 14:10 +0200

#171941 — Is nagle disabled?

Hi there


I'm experimenting with TCP to see how long it takes to send a small 
amount of data from A to B. One would expect a latency of a few hundred 
milliseconds, but it's a few hundred microseconds instead. It is as if 
Nagle's algorithm has been disabled.


Regards,
Rob

[toc] | [next] | [standalone]

#171945

> I'm experimenting with TCP to see how long it takes to send a small amount
> of data from A to B. One would expect a latency of a few hundred
> milliseconds, but it's a few hundred microseconds instead. It is as if
> Nagle's algorithm has been disabled.

I suggest you re-read https://en.wikipedia.org/wiki/Nagle's_algorithm
Nagle only kicks in when there are un-acknowledged packets.  So on the
first packet, there is no delay.  There will be a delay on the *second*
packet if it's small and we haven't yet received confirmation that the
first packet was received.


        Stefan

[toc] | [prev] | [next] | [standalone]

#171948

Hi there


On 09/09/16 18:19, Stefan Monnier wrote:

> I suggest you re-read https://en.wikipedia.org/wiki/Nagle's_algorithm
> Nagle only kicks in when there are un-acknowledged packets.  So on the
> first packet, there is no delay.  There will be a delay on the *second*
> packet if it's small and we haven't yet received confirmation that the
> first packet was received.

I thought I overlooked something. And this is it.
Thanks!


Regards,
Rob

[toc] | [prev] | [next] | [standalone]

#171976

Hi there


On 09/09/16 19:57, Rob van der Putten wrote:

> I thought I overlooked something. And this is it.
> Thanks!

So the question should have been 'Is delayed ack disabled'.
I have a hard finding decent information on the subject, so I did a bit 
of experimentation;
I send tiny bits of data (two bytes at a time) to a little echo  server. 
As it turns out, the use of delayed acks and therefore nagle, depends on 
the time between sending the bits of data and the RTT.


Regards,
Rob

[toc] | [prev] | [next] | [standalone]

#171977

[Multipart message — attachments visible in raw view] — view raw

Le quintidi 25 fructidor, an CCXXIV, Rob van der Putten a écrit :
> So the question should have been 'Is delayed ack disabled'.
> I have a hard finding decent information on the subject, so I did a bit of
> experimentation;
> I send tiny bits of data (two bytes at a time) to a little echo  server. As
> it turns out, the use of delayed acks and therefore nagle, depends on the
> time between sending the bits of data and the RTT.

I do not think you can really test delayed ACK with an echo server: the
principle of delayed ACK is to leave a little time to the application to
send a reply, because then the ACK can be bundled with the reply, saving a
packet.

With an echo server, the reply comes immediately, never letting the delay
for the ACK expire.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#171978

Hi there


On 10/09/16 13:37, Nicolas George wrote:

> Le quintidi 25 fructidor, an CCXXIV, Rob van der Putten a écrit :
>> So the question should have been 'Is delayed ack disabled'.
>> I have a hard finding decent information on the subject, so I did a bit of
>> experimentation;
>> I send tiny bits of data (two bytes at a time) to a little echo  server. As
>> it turns out, the use of delayed acks and therefore nagle, depends on the
>> time between sending the bits of data and the RTT.
>
> I do not think you can really test delayed ACK with an echo server: the
> principle of delayed ACK is to leave a little time to the application to
> send a reply, because then the ACK can be bundled with the reply, saving a
> packet.
>
> With an echo server, the reply comes immediately, never letting the delay
> for the ACK expire.

I use netcat6. From man nc;
nc6 --continuous --exec cat -l -p <port>
So the data goes from nc to cat and then back to nc.

Timestamps (epoch.microseconds) are dumped to a file on transmission and 
to an other file on reception of the 'echo'. Further check with tcpdump. 
Experiment on LAN and experiment over DSL;
When the time between the bits of data is larger then the RTT, data is 
send at two bytes per TCP packet.


Regards,
Rob

[toc] | [prev] | [next] | [standalone]

#171979

[Multipart message — attachments visible in raw view] — view raw

Le quintidi 25 fructidor, an CCXXIV, Rob van der Putten a écrit :
> I use netcat6. From man nc;
> nc6 --continuous --exec cat -l -p <port>
> So the data goes from nc to cat and then back to nc.
> 
> Timestamps (epoch.microseconds) are dumped to a file on transmission and to
> an other file on reception of the 'echo'. Further check with tcpdump.
> Experiment on LAN and experiment over DSL;
> When the time between the bits of data is larger then the RTT, data is send
> at two bytes per TCP packet.

With that kind of test, the reply comes immediately, the ACK is bundled with
the reply, therefore making delayed ACK invisible.

The way you implemented the echo server, with several applications
communicating with each other, is irrelevant because it is all invisible to
the network stack.

If you want to observe delayed ACK, you need to use a kind of server where
the reply does not come immediately in the same TCP stream. A discard server
would be the simplest example.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web