Created attachment 300251 [details] iperf test result We have a Qualcomm modem device which support MBIM and RMNET over USB. For RMNET, the download-link speed would be reduced to 80 Mb/s if re-connect it once. The expected speed should be 150 Mb/s. Test step as below: 1. Switch device to RMNET USB composition. 2. Connect it to host PC(kernel 5.13). 3. Start a data connection with nmcli related settings. 4. Start a iperf test with simulated network(CMW500). Test result is about 145 Mb/s ,and protocol is TCP. 5. Disconnect the connection by turning off the signal, setting AT+CFUN=0， or deleting the data connection in the host. 6. Re-connect it again. 7. The TCP iperf test could only reach to about 80-100Mb/s. This issue can not reproduced with MBIM port. Also, Windows can't reproduce the RMNET issue.
On Mon, Jan 10, 2022 at 11:23:13AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=215475 > > Bug ID: 215475 > Summary: RMNET data connection speed would be reduced to about > 80-100Mb/s from 150Mb/s if try to re-connect it > Product: Drivers > Version: 2.5 > Kernel Version: 5.13.0 Does this also happen on 5.16? > Created attachment 300251 [details] > --> https://bugzilla.kernel.org/attachment.cgi?id=300251&action=edit > iperf test result > > We have a Qualcomm modem device which support MBIM and RMNET over USB. > For RMNET, the download-link speed would be reduced to 80 Mb/s if > re-connect > it once. The expected speed should be 150 Mb/s. > Test step as below: > 1. Switch device to RMNET USB composition. > 2. Connect it to host PC(kernel 5.13). > 3. Start a data connection with nmcli related settings. > 4. Start a iperf test with simulated network(CMW500). Test result is about > 145 Mb/s ,and protocol is TCP. > 5. Disconnect the connection by turning off the signal, setting AT+CFUN=0， > or > deleting the data connection in the host. > 6. Re-connect it again. > 7. The TCP iperf test could only reach to about 80-100Mb/s. If you look at the usb traces, is the data the same? Any long pauses? thanks, greg k-h
Hi Greg, Yes, it also happen on 5.16. I tried it with 5.16-rc8. May I know what do you mean of 'usb trances'? USB protocol analyzer log or tcpdump packages? Actually, I do the same test with another Qualcomm modem device (not the same serials), and issue can't be reproduced with that device. Seems issue comes from firmware of device. But we can't explain the difference beween Windows and Linux. So do you have any advice to confirm whether the issue relate with the driver or not? Thanks!
On Wed, Jan 12, 2022 at 08:03:34AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=215475 > > --- Comment #2 from slark_xiao@163.com --- > Hi Greg, > Yes, it also happen on 5.16. I tried it with 5.16-rc8. > > May I know what do you mean of 'usb trances'? USB protocol analyzer log or > tcpdump packages? USB protocol analyzer log is best, to compare the data streams. > Actually, I do the same test with another Qualcomm modem device (not the > same > serials), and issue can't be reproduced with that device. Seems issue comes > from firmware of device. But we can't explain the difference beween Windows > and > Linux. Then please contact the vendor that wrote the firmware, they can help you out the best with this. good luck! greg k-h
Hi all, According to Qualcomm analysis, there is no issue on IPA side. They suspect that USB is slow to drain is the Root Cause. We tried to enable QMAP to speed up from host side. Ping test is okay, but failed in iperf test under simulator network. Do you have any good idea for further debugging? Thanks.
(In reply to slark_xiao from comment #4) > We tried to enable QMAP to speed up from host side. Ping test is okay, but > failed in iperf test under simulator network. QMAP has been set up successfully, but issue still exist. Any other idea from USB side?
Make a update about this issue. When we change rx_urb_size in the host side and keep it same as the QMAP related QMI, this issue is "fixed". I also checked some old commit which related with rx_urb_size, let's say https://patchwork.kernel.org/project/linux-usb/patch/20200803065105.8997-1-yzc666@netease.com/ and https://patchwork.ozlabs.org/project/netdev/patch/20200909091302.20992-1-dnlplm@gmail.com/#2524381. They tried to update the rx_urb_size to make QMAP works better. But these commits seems have been rejected. So do we have any new solutions or workarounds about changing the rx_urb_size?