Skip to contentSkip to conversation

New: RMNET data connection speed would be reduced to about 80-100Mb/s from 150Mb/s if try to re-connect it

Bug 215475 [email protected] 3 participants 9 messages Jan 10, 2022 – Mar 7, 2022 USB

lore
Share & tools
lore
#0 lore raw

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
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: USB
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

Created attachment 300251
--> 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.

This issue can not reproduced with MBIM port.
Also, Windows can't reproduce the RMNET issue.

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
#1 lore raw
Quoted 8 lines · On Mon, Jan 10, 2022 at 11:23:13AM +0000, [email protected]…

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?

Quoted 4 lines

Created attachment 300251
--> https://bugzilla.kernel.org/attachment.cgi?id=300251&action=edit
iperf test result

Quoted 13 lines

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

#2 lore raw

[Bug 215475] RMNET data connection speed would be reduced to about 80-100Mb/s from 150Mb/s if try to re-connect it

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=215475

--- Comment #1 from Greg Kroah-Hartman ([email protected]) ---

Quoted 8 lines · On Mon, Jan 10, 2022 at 11:23:13AM +0000, [email protected]…

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?

Quoted 4 lines

Created attachment 300251
--> https://bugzilla.kernel.org/attachment.cgi?id=300251&action=edit
iperf test result

Quoted 15 lines

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

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
#3 lore raw

[Bug 215475] RMNET data connection speed would be reduced to about 80-100Mb/s from 150Mb/s if try to re-connect it

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=215475

--- Comment #2 from [email protected] ---
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!

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
#4 lore raw

Re: [Bug 215475] RMNET data connection speed would be reduced to about 80-100Mb/s from 150Mb/s if try to re-connect it

Quoted 8 lines · On Wed, Jan 12, 2022 at 08:03:34AM +0000, [email protected]…

https://bugzilla.kernel.org/show_bug.cgi?id=215475

--- Comment #2 from [email protected] ---
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.

Quoted 4 lines

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

#5 lore raw

[Bug 215475] RMNET data connection speed would be reduced to about 80-100Mb/s from 150Mb/s if try to re-connect it

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=215475

--- Comment #3 from Greg Kroah-Hartman ([email protected]) ---

Quoted 8 lines · On Wed, Jan 12, 2022 at 08:03:34AM +0000, [email protected]…

https://bugzilla.kernel.org/show_bug.cgi?id=215475

--- Comment #2 from [email protected] ---
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.

Quoted 6 lines

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

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
#6 lore raw

[Bug 215475] RMNET data connection speed would be reduced to about 80-100Mb/s from 150Mb/s if try to re-connect it

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=215475

--- Comment #4 from [email protected] ---
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.

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
#7 lore raw

[Bug 215475] RMNET data connection speed would be reduced to about 80-100Mb/s from 150Mb/s if try to re-connect it

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=215475

--- Comment #5 from [email protected] ---
(In reply to slark_xiao from comment #4)

Quoted 2 lines

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?

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.
#8 lore raw

[Bug 215475] RMNET data connection speed would be reduced to about 80-100Mb/s from 150Mb/s if try to re-connect it

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=215475

--- Comment #6 from [email protected] ---
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/[email protected]/
and
https://patchwork.ozlabs.org/project/netdev/patch/[email protected]/#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?

Signature · 4 lines
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.