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]

Message-ID: <alpine.LNX.2.20.1602231455260.29937@localhost.localdomain>
Date:	Tue, 23 Feb 2016 14:57:41 +0100 (CET)
From:	sdrb@...t.eu
To:	Netdev <netdev@...r.kernel.org>
Subject: Re: Variable download speed


On Tue, 23 Feb 2016, Neal Cardwell wrote:

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

Hi,

I published example pcap file under following link:

https://www.dropbox.com/s/v8375ub16seyt1a/test7.pcap?dl=0

I hope it is possible to download it without creating dropbox account.

sdrb