All of lore.kernel.org
 help / color / mirror / Atom feed
From: Neal Cardwell <ncardwell@google.com>
To: sdrb@onet.eu
Cc: Netdev <netdev@vger.kernel.org>
Subject: Re: Variable download speed
Date: Tue, 23 Feb 2016 08:28:16 -0500	[thread overview]
Message-ID: <CADVnQyngzgLhbo6of1vTq5MH4mk4rSR6_KLWCCXkndK6QYynAw@mail.gmail.com> (raw)
In-Reply-To: <alpine.LNX.2.20.1602231216240.29937@localhost.localdomain>

On Tue, Feb 23, 2016 at 6:19 AM, <sdrb@onet.eu> wrote:
> My question is: what causes such dynamic change in
> the window size (while transferring data)?
> Is it some kernel parameter wrong set or something like this?

That sounds like TCP receive buffer auto-tuning (also called "Dynamic
right-sizing (DRS)" (Fisk and Feng, 2001):

  http://permalink.lanl.gov/object/tr?what=info:lanl-repo/lareport/LA-UR-01-5460

The Linux TCP receiver will, by default, dynamically adjust the
receive window to a value that supports the rate at which the
application successfully reads data out of the socket.

> Do I have any influence on such dynamic change in tcp window size?

You might check on the receiver host with top/mpstat/strace/etc to see
whether the receiving application is limiting performance in some way.
This kind of behavior can show up if the receiver is sometimes
CPU-saturated, or limited by the throughput of the medium on to which
it is writing the data.

If you control the receiver software, you can use
setsockopt(SO_RCVBUF) to explicitly set the receive buffer size, and
see if that helps. If it doesn't, that would suggest that it is indeed
the receiving application that is limiting performance.

If you could provide a tcpdump trace (headers only, e.g.,  -s 96)
taken on the sender, we could check to see if we can see any problems
in the TCP sender or receiver behavior.

cheers,
neal

  reply	other threads:[~2016-02-23 13:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-23 11:19 Variable download speed sdrb
2016-02-23 13:28 ` Neal Cardwell [this message]
2016-02-23 13:57   ` sdrb
2016-02-23 14:26     ` Neal Cardwell
2016-02-24  7:48       ` sdrb
2016-02-23 11:24 sdrb
2016-02-23 16:53 ` Rick Jones
2016-02-24  9:59   ` sdrb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADVnQyngzgLhbo6of1vTq5MH4mk4rSR6_KLWCCXkndK6QYynAw@mail.gmail.com \
    --to=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=sdrb@onet.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.