You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
time.monotonic in adafruit_wiznet5k_socket.py loses more and more precision the longer the uptime of the board, so if the board is in service for hours/days/weeks, depending on the timeout set, eventually the precision of the monotonic call will be coarser than the timeout setting. This will cause a spurious timeout when you happen to catch the coarse 'tick' of the monotonic clock for the timeout comparison.
I've seen this happen using wiznet5k with mqtt after a couple of days of uptime while using a socket timeout of 0.1s. A hard microcontroller reset will fix this, and longer socket timeout values should extend the uptime, but this isn't a good solution for a high uptime use case.
Likely shifting to monotonic_ns, or adafruit_ticks will solve this, but it will take some time to test.
The text was updated successfully, but these errors were encountered:
time.monotonic in adafruit_wiznet5k_socket.py loses more and more precision the longer the uptime of the board, so if the board is in service for hours/days/weeks, depending on the timeout set, eventually the precision of the monotonic call will be coarser than the timeout setting. This will cause a spurious timeout when you happen to catch the coarse 'tick' of the monotonic clock for the timeout comparison.
I've seen this happen using wiznet5k with mqtt after a couple of days of uptime while using a socket timeout of 0.1s. A hard microcontroller reset will fix this, and longer socket timeout values should extend the uptime, but this isn't a good solution for a high uptime use case.
Likely shifting to monotonic_ns, or adafruit_ticks will solve this, but it will take some time to test.
The text was updated successfully, but these errors were encountered: