The apple scada is rebooting frequently because the egauage power meter driver would fail to pat the watchdog.
responsive_sleep() will be fixed to check the requested end time and exit if that time is exceeded, which it always should have done. The default sleep granularity of drivers inheriting from SyncAsyncInteractionThread will also be increased from 0.01 to 0.1 because if we assume the variation is per-call and only on the positive side, then more calls means more aggregate delay.
Here's an example of an "ok" responsive_sleep:
It should do ~100 0.01 seconds sleeps. It mostly does that, though one sleep of 0.1 is fairly bad.
Here's an example of a responsive_sleep that caused the driver to miss its watchdog pat:
The fix described above should prevent this particular case from failing in this particular way, that seems like more sleep variation than we should have unless the CPU is just pegged and the GIL is not helping us. We might need to try running drivers in separate processes. Or something.
The
applescada is rebooting frequently because the egauage power meter driver would fail to pat the watchdog.responsive_sleep()will be fixed to check the requested end time and exit if that time is exceeded, which it always should have done. The default sleep granularity of drivers inheriting from SyncAsyncInteractionThread will also be increased from 0.01 to 0.1 because if we assume the variation is per-call and only on the positive side, then more calls means more aggregate delay.Here's an example of an "ok" responsive_sleep:
It should do ~100 0.01 seconds sleeps. It mostly does that, though one sleep of 0.1 is fairly bad.
Here's an example of a responsive_sleep that caused the driver to miss its watchdog pat:
The fix described above should prevent this particular case from failing in this particular way, that seems like more sleep variation than we should have unless the CPU is just pegged and the GIL is not helping us. We might need to try running drivers in separate processes. Or something.