RM500Q slow with qmi_wwan, fast with proprietary
Nick
mips171 at icloud.com
Sun Aug 21 12:45:17 UTC 2022
Hey,
Still haven’t made progress with MM multiplexing on OpenWrt except for adding support to use the multiplex parameter in the connect args. I’ll post what have in case anyone else has the same problem. This should just be an incompatibility with the OpenWrt netifd script, right? I am not quite sure if there would be anything else that needs to happen here because the documentation I have been able to find around this topic has been sparse.
After using QMICLI to set it up the connection I set up qmimux0 and wwan0 OpenWrt interfaces in the WAN firewall zone. As you can see this works fine.
root at OpenWrt:~# ip route
default via 10.210.81.132 dev qmimux0 proto static src 10.210.81.131
10.210.81.128/29 dev qmimux0 proto kernel scope link src 10.210.81.131
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
root at OpenWrt:~# ip link
4: wwan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 32768 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 36:36:d7:22:de:5e brd ff:ff:ff:ff:ff:ff
15: qmimux0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none
root at OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=113 time=61.536 ms
But after MM sets up the connection and manages the interface things are set up a little differently; MTU, links, number of links to name a few. I created network interfaces for these links and added them to the WAN firewall zone as before, however although the route seems to be configured correctly, pings to the gateway fail.
root at OpenWrt:~# ip route
default via 10.211.71.62 dev qmimux0 proto static src 10.211.71.61
10.211.71.60/30 dev qmimux0 proto kernel scope link src 10.211.71.61
192.168.1.0/24 dev br-lan proto kernel scope link src 192.168.1.1
root at OpenWrt:~# ip link
4: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 31744 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
link/none
15: qmimux0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none
16: qmimux1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none
17: qmimux2: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none
18: qmimux3: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/none
MM bearer
------------------------------------
General | path: /org/freedesktop/ModemManager1/Bearer/5
| type: default
------------------------------------
Status | connected: yes
| suspended: no
| multiplexed: yes
| interface: qmimux0
| ip timeout: 20
------------------------------------
Properties | apn: telstra.internet
| roaming: allowed
| ip type: ipv4v6
------------------------------------
IPv4 configuration | method: static
| address: 10.211.71.61
| prefix: 30
| gateway: 10.211.71.62
| dns: 10.3.64.162, 10.3.56.162
| mtu: 1500
Just as a control, here’s the interface using MM with multiplex=none
4: wwan0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
link/none
> On 15 Aug 2022, at 14:03, Nick <mips171 at icloud.com> wrote:
>
> Just following up on this because I’m working on adding support to use this on OpenWrt. I am not sure what the issue is but perhaps it could be an issue with the MM netifd script on OpenWrt? I passed in the multiplex=$value to the connectargs then brought up the interface. Everything looks normal except it that it seems traffic is transmitted over the interface but nothing is ever received. I have tried removing the extra QMIMUX interfaces (del_mux 4,3,2) to make it close to the same configuration as when setting up with qmicli, however no joy. Is anyone able to replicate this?
>
>
> Best,
> Nick
>
>> On 13 Aug 2022, at 17:48, Nick <mips171 at icloud.com> wrote:
>>
>> I have tried using ModemManager now with `multiplex=required` in the bearer options and it connects with 4 QMUX interfaces, netifd assigns the IP address to the qmimux0 interface, I have a default route via that interface, everything looks good but... I can’t ping the internet. It looks like wwan0 is now the qmux main interface, with a large MTU (31744). Is there some extra step required to use this? What could I be missing?
>>
>> Best,
>> Nick
>>
>>> On 13 Aug 2022, at 15:19, Nick <mips171 at icloud.com> wrote:
>>>
>>> I did some testing with this advice and have some results and a couple more questions.
>>>
>>> Bjørn, I realise now you were talking about cdc-mbim. I checked the values for tx_max and rx_max which are both 16384 by default on my device. I am able to change rx_max to 31744, which seems to improve upload slightly, but I cannot change tx_max (Permission denied, and after changing file permissions I just get an I/O error). Is that value supposed to be user accessible? Is this value tied to dwNtbOutMaxSize? Using cdc-mbim with these settings I get consistently 200Mbps, so my feeling is the bottleneck could be tied to these values, since I’m able to change their counterparts in the QMI driver. Using QMI QMAP it gets much faster than before, about 450Mbps.
>>>
>>> Another question more ModemManager related; is there a way to set up a connection using user-specified QMAP values like the ones Sebastian provided?
>>> >qmicli -p -d /dev/cdc-wdm0 --client-cid=1 --wda-set-data-format="link-layer-protocol=raw-ip,ul-protocol=qmap,dl-protocol=qmap,dl-max-datagrams=32,dl-datagram-max-size=32768,ep-type=hsusb,ep-iface-number=4" --client-no-release-cid
>>>
>>> Best,
>>> Nick
>>>
>>>> On 11 Aug 2022, at 17:47, Bjørn Mork <bjorn at mork.no> wrote:
>>>>
>>>> Nick <mips171 at icloud.com> writes:
>>>>
>>>>> Hey,
>>>>>
>>>>> I am testing a Quectel RM500Q on OpenWrt master, and have noticed to
>>>>> my surprise that the speed is much slower when using the qmi_wwan with
>>>>> MM than it is when using qmi_wwan_q and quectel-CM (Quectel’s
>>>>> proprietary driver and connection manager).
>>>>
>>>> This is sort of expected since the qmi_wwan driver will use one USB
>>>> transaction per IP packet whereas the qmi_wwan_q will buffer a number of
>>>> packets per transaction.
>>>>
>>>> There is some built-in support for MAP (RMNET muxing, which implies
>>>> buffering) in qmi_wwan. But I recommend using the more recent rmnet
>>>> driver for that, with qmi_wwan in pass-throuh mode. This is supported
>>>> by recent ModemManager/libqmi. Ref
>>>> https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/447
>>>>
>>>>> Under good signal conditions the speed tops out at around 100Mbps on
>>>>> qmi_wwan + MM (and is a little bit faster when in MBIM mode with MM),
>>>>> but switching to qmi_wwan_q and quectel_CM it gets the expected
>>>>> 700Mbps+ where I am. Is there an easy explanation for this? Any
>>>>> suggestions as to what I can change to get speeds equivalent to the
>>>>> proprietary stack?
>>>>
>>>> I'm a little surprised that you don't get better numbers in MBIM mode.
>>>> It should have the same advantages as qmi_wwan_q or qmi_wwan+rmnet. I
>>>> must admit that I haven't done any seriuos testing of this theory myself
>>>> though. But "A little bit faster than 100Mbps" is unexpectedly slow.
>>>> I'm pretty sure we can do much better than that in MBIM mode.
>>>>
>>>> What kind of hardware is the host running? Maybe we have some alignment
>>>> issue punishing this hardware? Or maybe the buffers we use are
>>>> sub-optimal for thise host+device combo? You could try to adjust some
>>>> of the writable settings in /sys/class/net/wwan0/cdc_ncm/ (replace wwan0
>>>> with your interface name)
>>>>
>>>>
>>>>
>>>> Bjørn
>>>
>>
>
More information about the ModemManager-devel
mailing list