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: <CADVnQy=UOvC06TBOE7d7WvuKm1Tdkzu7M4dfvm6VRcRJaDMyLw@mail.gmail.com>
Date:	Wed, 15 Feb 2012 14:44:10 -0500
From:	Neal Cardwell <ncardwell@...gle.com>
To:	Netdev <netdev@...r.kernel.org>, alekcejk@...glemail.com
Subject: Re: Re: Re: Re: Re: Re: Re: Re: limited network bandwidth with 3.2.x kernels

Thanks, Eric, for the clarification.

I am still intrigued by these aspects of the issue:

> Also I want to pay attention that limited speed stays constant - always
> 5.5 MB/s with straight line on traffic plotter as if was network bandwidth shaping.
> With 3.1 kernels this never happens - speed can vary in some ranges
> but at maximum it is about 11 MB/s, no limitations such as 5.5 MB/s.
...

> But I can say that probably there is really 100Mb/s
> with Full duplex because as I wrote in first mail
> there is some servers which have almost the same
> speed with 3.2.3 kernel as with 3.1.10.
> They are mostly located geographically close to me
> (maybe there are other servers, not close, but I not found such one).
> Here example of such server ftp.linux.kiev.ua,
> download speed 11,1 Megabytes/s with both kernels.
...

To me, these symptoms smell like a receiver window issue that is
capping bandwidth at some receive_window/RTT value:

1) when there is a problem bandwidth is a "straight line" instead of
typically variable TCP performance

2) when there is a problem, it is with geographically remote
(high-RTT) sites and not local sites

3) the problem only shows up when certain versions of the kernel act
as a receiver

I would be intrigued to see the following pieces of info for a slow
transfer (from a geographically distant server) with the problematic
3.2 kernel:

- tcpdump of first 300 or so packets to see SYN/SYNACK and RTT

- tcpdump of last 300 or so packets, to see the steady-state dynamics
  with receiver window and packet inter-arrival times

- summary of overall throughput wget sees

(I apologize if this is already in the thread somewhere... there are
now a lot of traces in the thread and it's hard to scan them all...
:-)

neal
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ