> 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 <[email protected]> wrote: > On Wed, May 10, 2017 at 4:34 PM, Carlo Lobrano <[email protected]> > 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 >
_______________________________________________ ModemManager-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
