[PATCH 2/2] dell: removed ID_MM_TELIT_PORTS_TAGGED dependency

[Carlo Lobrano]

> The retries logic is in case the port needs some time to reply, so
> probably doing the retries only for the first command would make
> sense, and this would get us 4 commands removed for all.
>
> But also, is there a modem that doesn't reply to AT+GMI at all? i.e.
> just not replying anything? I doubt it, so we could also see if all
> AT+GMI retries failed with a timeout error, and if so we just assume
> it's not an AT port directly. This would actually have a better effect
> than your patch, because we not only skip the CGMI or ATI commands,
> but also the extra "AT"-only commands that I also see in the logs.
>
> What do you think? I think the last approach could be very useful here.

I think that's a nice solution! I'll develop the new patch2 for this. Doe
this affect also the part 1 of the patch? I mean, do you want me to submit
again even part 1?


On 10 May 2017 at 21:22, Aleksander Morgado <aleksander at aleksander.es>
wrote:

> On Wed, May 10, 2017 at 4:34 PM, Carlo Lobrano <c.lobrano at gmail.com>
> wrote:
> >> Could you gather debug logs using the Telit/Dell modem in 2 different
> >> runs:
> >>    * with the custom block setting cgmi_retries=0 and ati_retries=0 in
> >> the Dell plugin (as in git master)
> >>    * and without it (e.g. just removing that block)
> >
> >
> >
> > Ok, this is equivalent to test it once with MM master, and once with MM
> > master but without Dell udev rule to tag Telit modems, right?
>
> Yes
>
> > The results are attached to this email
>
> So, without the udev rule it takes 51s to probe all ports doing all
> retries for all commands. With the udev rule in place it gets a bit
> better, and takes 30s to do all port probing (you removed 6 AT
> commands with the udev rule: 3 CGMI, 3ATI).
>
> I'm tempted to say that instead of:
>     ctx->gmi_retries = 3;
>     ctx->cgmi_retries = 3;
>     ctx->ati_retries = 3;
>
> We could do:
>     ctx->gmi_retries = 3;
>     ctx->cgmi_retries = 1;
>     ctx->ati_retries = 1;
>
> The retries logic is in case the port needs some time to reply, so
> probably doing the retries only for the first command would make
> sense, and this would get us 4 commands removed for all.
>
> But also, is there a modem that doesn't reply to AT+GMI at all? i.e.
> just not replying anything? I doubt it, so we could also see if all
> AT+GMI retries failed with a timeout error, and if so we just assume
> it's not an AT port directly. This would actually have a better effect
> than your patch, because we not only skip the CGMI or ATI commands,
> but also the extra "AT"-only commands that I also see in the logs.
>
> What do you think? I think the last approach could be very useful here.
>
> --
> Aleksander
> https://aleksander.es
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20170511/cad59738/attachment.html>