Modemmanager significant startup delay
Aleksander Morgado
aleksander at aleksander.es
Sun Aug 25 13:15:41 UTC 2019
On Thu, Aug 22, 2019 at 11:06 AM Bjørn Mork <bjorn at mork.no> wrote:
>
> Dan Williams <dcbw at redhat.com> writes:
> > On Wed, 2019-08-21 at 12:23 +0000, Amol Lad wrote:
> >> Please help with this. What could be the cause of significant MM
> >> startup delay?
> >
> > When started, or when a new modem is plugged attached, ModemManager
> > runs through a hardware detection sequence to figure out whether the
> > thing you attached is actually a modem and what ports it has and what
> > protocols those ports speak.
>
> Not prepared to write the code, so I should probably not make
> suggestions... But do anyway ;-)
>
> How about caching protocol probe results and skipping the full probe if
> a match is found?
>
> Keying the cached data and knowing when to ignore the cache is probably
> the hard part. But I believe there is a lot to gain for normal use
> cases. Most people don't use lots of modems. Many systems will have
> the same modem connected to the same port for extended periods. Some
> system designs cause the MM probing to run very often, "always"
> returning the same result. Looking at my laptop for example: It turns
> off power to the internal wwan slot on suspend. So MM must probe the
> modem on every resume, causing a significant delay from the system
> appears to be up until the network is up again.
>
> The protocol probes are obviously a waste of time in this case. Unless I
> am messing with drivers or descriptors :-) But that's easy to detect.
> You could just ignore the protocol cache if any of the udev data
> changed. It would still be a large win for most cases.
>
I like this idea very much! I've opened a new issue to track this:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/142
--
Aleksander
https://aleksander.es
More information about the ModemManager-devel
mailing list