netdev - Re: Variable download speed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Feb 2016 08:28:16 -0500
From:	Neal Cardwell <ncardwell@...gle.com>
To:	sdrb@...t.eu
Cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: Variable download speed

On Tue, Feb 23, 2016 at 6:19 AM, <sdrb@...t.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