-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TCP bandwidth drops to zero #1021
Comments
I am also facing a similar issue. I debugged a lot. Not able to figure out. iperf3 version on windows client is 3.1.3 and iperf3 version on Macbook server is 3.7. Kindly help me out!
|
@PreetiMSobarad, can you also list the server's iperf3 command?
|
Hey David, thank you so much for responding. I have attached iperf3 session from server side and from client side. I have attached 2 iperf3 sessions from client side. One is where I am facing the issue with windows as client and Macbook as server. and another is iperf3 with -R flag which works fine with Macbook as client and Windows as server. Please take a look at it and kindly help me out. Awaiting to hear back from you. |
@davidBar-On Kindly help me out! |
@PreetiMSobarad unfortonattely I don't see much additional useful information in the new log files. I am surprised that the 180 seconds test did not timeout, as it seems that that two 128KB buffers ((131,072 bytes - the default size) that were sent by the client (the 256KB) may even didn't get out of the Windows machine. It seems that this issue is similar to #839. As @bmah888 noted there, version 3.1.3 used on Windows is 4 years old, so it might help if you will use newer version of iperf3. If newer version doesn't help, or if you want to try other options first:
|
Hello, @bmah888 According to the below link, the latest version for iperf3 Windows is 3.1.3. Do you know where I can get 3.7 version for Windows? https://iperf.fr/iperf-download.php#windows |
Hello @davidBar-On , I did as you said. There is traffic going through when the buffer is kept low and bandwidth is kept low. Do you know whats wrong when we dont put any flag? I have attached files. one is iperf3 with buffer flag and another is iperf3 with bandwidth flag. I connected just my windows machine and intermediate server. I think something is wrong with the way windows is sending data. In the same place when I use Macbook it works. Do you know anything about particular windows iperf3 setting that's causing this issue? I am unable to attach wireshark capture files because its not supported on github, but it seems fine. |
Hi @PreetiMSobarad, from the logs it is quite clear that for some reason the Windows computer Tx bandwidth is very limited - few 10s of KB/sec. The reason Tx from Macintosh is working is that in this case Windows only sends acks which require very low bandwidth. It seems that the reason in the 128KB buffer (default) case almost no data is reported as received, is because TCP gets into heavy cycles of retries, so most of the data received at the other end are the retries. That can be seen in the "BUFFER SIZE OF 16384 BYTES" case, were it takes about 4 sec to transfer each of the 16KB buffers. The reason for the average 4KB/sec in this case, compared to the the about 10KB/sec with short buffer is probably the retries. I assume that gets worth with the 128KB buffer. It doesn't seem that the problem is in iperf3. Wireshark logs on Windows side for the default buffer length case (and maybe also the 16384 BYTES case) may allow me or others to help. I think you can attach Zip of the Wireshark log. |
@davidBar-On I see. I tried to increase the buffer size of my Windows machine but that still did not work. I followed this link to do so. Do you have any other suggestions? I am attaching wireshark captures. Wireshark.pcapng is the one that has the issue. wiresharkbuff.pcapng is the one with buffer. Kindly let me know if you want any other captures. |
@davidBar-On The link i used to change buffer size of windows machine - http://smallvoid.com/article/winnt-winsock-buffer.html |
@PreetiMSobarad, from the Wireshark logs it seems that the main issue is related to fragmentation. In both cases, TCP sends packets of up to about 1460*10 bytes with "don't fragment". Router/switch/interface card in the Windows machine/... with IP address 192.168.100.4 sends back ICMP that next hop (the Macintosh? Router? ...) MTU is 1500 and fragmentation is needed. Issue I don't understand is that when TCP already knows that path MTU is limited to 1500, it still continue to send larger packets with larger size. Only after receiving the ICMP it restransmits it with proper packets size. From what I read, it may not be good idea to allow TCP packets to be fragmented. Therefore, try to reduce the MTU of the relevant interface on the Windows machine to 1500 (I would expect that now it is about 14KB). Try first my using the iperf3 option "-M 1460". Another option is to set the Windows machine MTU to 1500. Example of instructions for how to do that on Windows 10: https://myrandomtechblog.com/cryptomining/change-mtu-size-in-windows-10/. Even if one the options works, please send for information what is the current MTU size. |
Hello @davidBar-On I checked the interfaces of all the devices through which data is traversing. The MTU is set as 1500. I tried to change the MTU from command line using flag but I got an error. In the Windows machine too, MTU is set to1500. |
Hi, searching the internet it seem that setting MSS on Windows is not supported .... In any case, since all interfaces are with MTU 1500 that wouldn't help anyway. Also, I see that both SYN and SYN ACK from Windows and Macintosh during the TCP initialization report MSS=1460. I now believe that the issue is related to NIC TCP Offload. This will also explain why TCP continues to send large packets. TCP Offload is when some TCP functions are offloaded to the NIC to save main CPU performance. Mainly it is related to un/segmentation of large packets and checksum computation. For the sending side the most known terms are TCP Segmentation offload (TSO) and in Windows the main term used is Large Send Offload (LSO). If LSO is indeed active, then for some reason it doesn't take the reported MSS into account. Therefore, as a next step I suggest to disable LSO, at least on the relevant port. See for example: https://atomicit.ca/kb/articles/slow-network-speed-windows-10/. If that will not help then the only other suggestion I have is to try disabling the "Don't Fragment" flag of TCP. See for example: https://support.microsoft.com/en-us/help/900926/recommended-tcp-ip-settings-for-wan-links-with-a-mtu-size-of-less-than. |
Hey @davidBar-On , I tried to disable LSO on windows. It did not help fix the initial issue but i do see improvement in the speed when I use small size buffers. Thats the only improvement I am able to see so far. But the bandwidth again becomes zero when the buffer size goes to 8KB. I have attached a text document that shows different buffer length and different bandwidth. Using the second link, when I enabled PMTU (Dont fragment bit off), that made the bandwidth to drop compared to LSO disabled. I am attaching wireshark captures. One with LSO disabled and another one with LSO disbaled and PMTU enabled- |
Hi @PreetiMSobarad, the "LSOdisabled" Wireshark log shows that test was successful - over 330MB were successfully send during the 10 seconds (for some reason each chunk sent is 1536 bytes, which is split into 1460+73 bytes packets). Can it be that it really worked successfully or by mistake you attached the Wireshark log for one of the small buffer tests? Regarding don't fragment test. The don't fragment bit is still set, but packet size is reduced to 536, i.e. instead of unsetting the flag the TCP stack reduces the packet size to almost minimum. That should have worked successfully, but per the ICMP "fragmentation needed" error the packets are combined to 2-3KB packets before sending. Try using the "--no-delay" option that can help preventing combining the packets. If that doesn't help it may be that LSO was not disabled. |
ESnet doesn't produce binaries for Windows or any other platform, we only release source code. I'm sure if you use your favorite search engine you can find a Windows binary somewhere (just be aware that iperf3 is not an officially supported platform, and we can't take any responsibility for any binaries that a third party has made available). |
@PreetiMSobarad, can you update about the status of the problem? Did it help to disable the LSO? Did anything else help? |
Hello @davidBar-On disabling LSO did help me a little bit in pushing more data. But not the level I was expecting. But I think there's something wrong with my windows machine to be behaving like this. I'm marking this issue as solved. You have given many steps to debug and if someone is facing this issue can use these to resolve their issue. |
@PreetiMSobarad , thanks. I have created issue #1029 with suggested documentations based on the debug steps suggested for this issue. You can close this issue. |
Hello, I am having the same issue here. What is the final solution? |
@wongex23, there are several potential causes for this issue. Please send the commands you used and the client input. Also specify which iperf3 version you are using you should send the commands you are using and on what OS. |
I have a similar issue. 10 Gbit in one direction, 0 in the other.
Any idea how I can improve this? Why is TCP bandwith dropping to 0 in one direction when MTU is 9000? |
@FudiHub, few questions:
|
Thanks for your questions:
But I am not sure why my OPNsense should not be able to handle 9K packets. Its a DEC740. Edit: Reading the results of iperf with MTU 4000 on client side 1668 packet had to be retransmitted... also not a good result, right? |
Few tests that may help to better understand what may be the problem (when MTU is 9000):
|
The behavior occurs on Linux 4.19.124-RT,
UDP works fine, on TCP the bandwidth drops to zero after few seconds.
Ethernet driver is virtual driver between to PCIe machines.
The driver is quiet stable, and no observed problems with software (scp, ssh, etc)
No packet drops on the Ethernet driver.
I would love to understand why iperf3 stops sending packets, is there a way to enable more debugging, or somewhere I could look to debug it further ?
Version of iperf3:
3.7
Hardware:
MIPS based Embedded Linux board
Operating system (and distribution, if any):
Buildroot 20.02
Other relevant information (for example, non-default compilers,
libraries, cross-compiling, etc.):
Cross compiler:
mips-img-linux-gnu-gcc (Codescape.GNU.Tools.Package.2019.02-01.for.MIPS.IMG.Linux.CentOS-6.x86_64.tar.gz)
Bug Report
Bandwidth is stable
Bandwidth drops to zero, no packets are sent from iperf.
Running on the HW
The text was updated successfully, but these errors were encountered: