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.
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.