Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v4.12 kernel[0].

If this bug is fixed in the mainline kernel, please add the following
tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag:
'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as
"Confirmed".


Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.12-rc5

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1698454

Title:
  TCP/IP Throughput Limitation

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  I'm having a severe TCP receive problem with a new Ubuntu 16 server
  and an Intel 82599ES 10-Gigabit SFP+ (X520 series card) when a windows
  10 machine is used to send the data. The receive performance is 1Gb to
  2Gb steady using iperf single stream, while send is 9.42Gb.

  Here is what I have found:

  -Running 8 parallel streams in iperf gets me the full 9.42 in
  aggregate

  -Tried a few windows 10 machines with repeatable same results

  -Same results through switch or direct

  -Linux to linux no problems

  -Tested with clean installs of 16.04.02 and 4.4.0-66 kernel, latest
  the upgrade will give me, also tried 17.04 with up to
  4.10.0-20-generic same problem, tried 4.11.0-041100rc8-generic and
  problem seemed to go away for a bit but came back so I think that
  might be a red herring (see interesting note below).

  -14.04 and 15.10 with up to 4.2.8-040208-generic is 9.42/9.42 (works
  fine, couldn't get 4.3 to install on 15.10)

  -14.04 with the latest 5.0.4 ixgbe driver still works fine, does not
  seem to be a driver version issue.

  -Tried swapping out cards with another same model/chipset with same
  exact result

  -Large receive offload increases the performance from a steady 1Gb to
  a steady 2.14Gb

  -Disabling sack under got me 75% of the way back to full speed, but it
  was very unstable (didn't hold at a solid speed)

  -Using a different brand of card in this same server (but not the same
  slot) (mellanox infiniband running in ethernet mode) is 9.42/8.5
  (seems to work fine, 9.42 to 8.5 is windows machine limit I think)

  -Interesting: When swapping between intel and mellanox 10Gbe cards
  (with a reboot of the server inbetween, but not a reboot of the
  windows machine, and keeping the same IP on the server) the
  performance does not change immediately. When going from intel to
  mellanox the first test holds around 1 or 2Gbit, then after that it
  jumps up to 8.5 steady. Similarly when switching from mellanox to
  Intel the first 1 or 2 seconds of performance hits 8.x then drop in
  half or more and within 3 or 4 seconds it is back to 1Gbit and stays
  there for each subsequent iperf test.

  -Interesting: When capturing packets on wireshark on windows,
  performance comes up to 8.5! (No, ditching windows isn't an option
  here unfortunately. :) So obviously something in the way the two tcp
  stacks are interacting without a buffer inbetween when the intel
  driver is online is causing issues.

  -Port bonding makes no difference (nor should it for single stream)

  -Tried rolling the intel driver back to the 3.2.1 version that is on
  14.04 but it was too old to compile

  -I suspect this is a kernel TCP/IP implementation change somewhere
  between 4.2 and 4.4 that has caused it to not play nice with window's
  stack.  Based on the delayed performance change I'm thinking something
  is messing with flow control, the tcp congestion algorithm, or the tcp
  window. I tried turning some various tcp options off, tweaking some
  values, changing congestion algorithms, hardware flow control, and
  comparing sysctl stuff from the u14 machine to this machine to no
  avail.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1698454/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to