Reduce polling frequency of usb serial scanner

[bjoernbrings]

As discussed in a side discussion in issue #829 the most CPU consumption (after #763 and #861 have been implemented) is the USB polling.
I'd propose to reduce the polling frequency from 5 to 60 sec.

Signed-off-by: Björn Brings [email protected]

[maggu2810]

Let's wait for a comment of the initial author.
I suppose there were a few reasons (or at least one) why the current delay has been chosen.

[maggu2810]

Related to: eclipse-archived/smarthome#5315

@hsudbrock Can you comment?

[hsudbrock]

Thanks for the ping, Markus; I am only on phone now, will answer when I get to laptop later. Am 21. Juni 2019 08:27:49 MESZ schrieb Markus Rathgeb <[email protected]>:

…

Related to: eclipse-archived/smarthome#5315 @hsudbrock Can you comment? -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #889 (comment)

[hsudbrock]

The reasons why I set the default polling frequency to 5 seconds were

• (a) that longer polling periods lead to longer delays until a USB device is discovered and I did not want a user to wait for, say, 30 seconds until the discovery result appears in the inbox after plugging the stick in, and
• (b) that it did not lead to 'too high' CPU consumption on the not-so-powerful embedded hardware I tested with.

If CPU consumption has become an issue, and the default USB polling frequency needs to be reduced because this issue is a problem for too many users, I think that it should be fine to set the default to 60 secs; if a user (or a solution integrating the USB discovery) wants faster feedback, the frequency can be configured to another value (as far as I recall, I made most settings for the USB discovery configurable via OSGi config admin).

[maggu2810]

Without digging into the current implementation... would it be possible if we introduce a "serial interface scanner" Java interface that every implementation publishes as an OSGi service.
The "serial interface scanner" provides a method "scan now".
There could be a "serial interface scanner manager" that collects all "serial interface scanner" and calls "scanNow" for each implementation if the "scanNow" method of the manager is called.
A binding using a serial interface can reference the manager (using OSGi DS) and trigger "scanNow" if his background / foreground scanning is triggered.
So, if an user wants to search for a new device, new serial interfaces will be scanned, to.

Don't know if this makes sense at all.
@hsudbrock Can you comment?

[kaikreuzer]

@bjoernbrings Looking at the numbers of #829, it does not seem to be "high" resource usage by this thread - it is similar to the ssh server thread, which is also just some background thread.

I see the point of @hsudbrock that it is nice to get a direct feedback (auto-discovery) when a USB dongle is plugged in - 60 seconds would very much destroy this user experience. On the other side, it is a very rare activity, which might not be worth having a permanent background activity.

Maybe 10-15 seconds could be a compromise? And there were discussions about fully disabling background discovery for "fully set up systems" - so this could solve the second point above.

[mhilbush]

10-15 seconds seems quite reasonable, as the user won't get impatient when the device isn't discovered quickly.

Plus, it really is very simple to change the value to something large enough to make the CPU consumption blend into the background noise. Thanks to @hsudbrock who had the foresight to make it configurable. 👍

I have mine set to this, and it's way, way down on the list of CPU-consuming threads -- effectively disabled for all practical purposes... And, as you know, I've been looking at this list of threads a lot lately. 🙄

discovery.usbserial.linuxsysfs.pollingscanner:pauseBetweenScansInSeconds = 600

[Gozilla01]

discovery.usbserial.linuxsysfs.pollingscanner:pauseBetweenScansInSeconds = 600
Hello,
I don't use USB devices
Where does this parameter change?
I find nothing in the documentation.
Thank you

[mhilbush]

Where does this parameter change?

services/runtime.cfg

[Gozilla01]

Thank you.

[bjoernbrings]

Fine for me, adjusted as suggested.
Just wanted to highlight that it's one of the top CPU consumers ...

[hsudbrock]

Without digging into the current implementation... would it be possible if we introduce a "serial interface scanner" Java interface that every implementation publishes as an OSGi service.
The "serial interface scanner" provides a method "scan now".
There could be a "serial interface scanner manager" that collects all "serial interface scanner" and calls "scanNow" for each implementation if the "scanNow" method of the manager is called.
A binding using a serial interface can reference the manager (using OSGi DS) and trigger "scanNow" if his background / foreground scanning is triggered.
So, if an user wants to search for a new device, new serial interfaces will be scanned, to.

@maggu2810 I am not quite sure if I understand what your goal is here. Are you talking about having something like a "USB/Serial interface scanning service" that could be used by bindings directly, instead of "forcing" the bindings to plug into the current USB/Serial discovery service? If I understand this correctly then I think that, technically, this should be possible.

[maggu2810]

@hsudbrock I realized that I did not answer your question yet. As it has been already merged I assume we can leave the situation as it is.