TCP/IP Throughput Limitation

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1698454/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1698454

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

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

I will do that, won't be until end of next week though when I have access to it.

> On Jun 19, 2017, at 8:01 AM, Joseph Salisbury <email address hidden> wrote:
>
> 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 subscribed to the bug
> report.
> 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 subs...

Tested with mainline v4.12-rc7, bug still exists. Added tag kernel-bug-exists-upstream and changed to Confirmed

Is this something I should try to report elsewhere as a kernel bug? I haven't tried a dist other than Ubuntu yet.

My initial conclusion on something changing in the Kernel was incorrect. I've since tested 17.04 all the way back to 4.2.8 and it still fails. I've also tested 15.10 up to 4.3.6 and it works correctly. So something in Ubuntu's implementation changed between 15.10 and 16.04 that is causing this bug.

Testing was with mainline builds in both cases, so it should rule out the kernel.

In light of my previous findings I did a dual boot install with 15.10 and 16.04. I put both installs on 4.3.6 mainline kernel and found that 15 was fine and 16 was not. I started looking at installed packages and tried to isolate some packages. After uninstalling several and rebooting I found that my performance went back up to normal. Long story short I found that uninstalling libnuma1 (which also uninstalls irqbalance) solved the problem after a reboot. FYI simply killing the irqbalance task did not solve the problem. I haven't taken time to troubleshoot further but it's something with numa/interrupt processing that is taking too long or something. Reinstalling irqbalance/libnuma1 causes the problem again. This is a single Xeon CPU on a dual CPU board.