qmicli slow compared to mmcli and AT commands

Amol Lad Amol.Lad at 4rf.com
Thu Sep 5 06:45:13 UTC 2019


Thanks Aleksander,

This works!

Amol


The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).-----Original Message-----
From: Aleksander Morgado <aleksander at aleksander.es>
Sent: Monday, 2 September 2019 12:46 PM
To: Amol Lad <Amol.Lad at 4rf.com>; libqmi-devel at lists.freedesktop.org
Subject: Re: qmicli slow compared to mmcli and AT commands

Hey,

>
> I'm using Solidrun's clearfog-base plarform with Sierra Wireless EM7430 LTE chipset. I'm running OpenWRT 18.06 with ModemManager feed from https://gitlab.freedesktop.org/mobile-broadband/mobile-broadband-openwrt which pulls in libqmi as well.
>
> I noticed that qmicli is slow compared to mmcli or even AT commands read from the modem. For example:
>
> It takes around 160ms for qmicli to produce result (or exit?). I noticed this when I had 4-5 qmicli commands in one script and can observe noticeable slowness.
>
> Please advise what could be going wrong?
>
> root at OpenWrt:/# time qmicli -d /dev/cdc-wdm0 -p --dms-uim-get-imsi
> [/dev/cdc-wdm0] UIM IMSI retrieved:
>         IMSI: '405861062273068'
>
> real    0m0.151s
> user    0m0.016s
> sys     0m0.000s
>

So this is qmicli, without reusing client ids and through the proxy. See below.

> root at OpenWrt:/# time mmcli -i 0
>   ---------------------------
>   General    |     dbus path: /org/freedesktop/ModemManager1/SIM/0
>   ---------------------------
>   Properties |          imsi: 405861062273068
>              |         iccid: 89918610500008980672
>              |   operator id: 405861
>              | operator name: Jio 4G
>
> real    0m0.024s
> user    0m0.020s
> sys     0m0.000s
>

Please note you cannot compare mmcli to the other commands, because in the mmcli command you're NOT talking to the device, you're talking to ModemManager daemon, which has preloaded that information being shown, so you're really talking between two processes through DBus, nothing else.

> root at OpenWrt:/# time chat -t 1 -V '' AT+CIMI OK\\r < "/dev/ttyUSB2" > "/dev/ttyUSB2"
>
> 405861062273068
>
> OK
> real  0m 0.08s
> user    0m 0.00s
> sys     0m 0.00s
>


Part of the slowness may be because you're not reusing client IDS. If you run qmicli without preallocating and reusing client IDs, then each of the qmicli commands you run will go through the process of allocation/deallocation:
 * Allocate client ID
 * Run specific command
 * Deallocate client ID

If you want to run multiple qmicli commands, e.g. in a script, the way to go is to allocate the client ID ONCE, and re-use it over and over until you don't need it any more. E.g.:

// Allocate DMS client ID by running a noop command, and make sure it's NOT released $ qmicli -d /dev/cdc-wdm0 -p --dms-noop --client-no-release-cid // The result of the command will tell you which is the CID that was allocated, e.g. "1"

// After that, you can run qmicli DMS commands reusing the client id, e.g.
$ qmicli -d /dev/cdc-wdm0 -p --dms-uim-get-imsi --client-cid=1 --client-no-release-cid

// Once you're done using your client ID, e.g. if your script finishes, make sure to deallocate the CID (by skipping --client-no-release-cid), e.g. with another noop $ qmicli -d /dev/cdc-wdm0 -p --dms-noop --client-cid=1



--
Aleksander
https://aleksander.es


More information about the libqmi-devel mailing list