CLOCK_REALTIME should be CLOCK_MONOTONIC

[diablodale]

Throughout depthai-core and Xlink I believe CLOCK_REALTIME is wrong. It should be CLOCK_MONOTONIC but there is a problem in POSIX's semaphore API. 😕

The code everywhere is relative time when CLOCK_xxxx is used with apis like clock_gettime().

However...

• CLOCK_REALTIME is like a clock on your kitchen wall. That clock can move forward or backward due to LAN servers updating network time, NTP servers changing time, leap seconds, etc. It is not reliable for use in depthai-core and xlink.
• CLOCK_MONOTONIC is monotonic time since some unspecified starting point, it can never be changed or set by an admin, server process, NTP, leap seconds, or anything else

Changing all the code to use CLOCK_MONOTONIC will ensure that watchdogs, semaphore timeouts, PoE devices, and all kinds of other sensitive timing thing are not affected by clock changes.

There is a problem. XLink uses POSIX apis like pthread_mutex_timedlock(), pthread_cond_timedwait(), and sem_timedwait(). They all accept an epoch-time parameter. But clocks based on epoch are realtime wall-clocks. They vary positive and negative as described above. This is a known issue with those POSIX apis.
https://www.club.cc.cmu.edu/~cmccabe/blog_time_and_time_again.html
https://bugs.eclipse.org/bugs/show_bug.cgi?id=569084

Other mutex and semaphore apis like Boost, Windows, etc. do not have this bug.

[diablodale]

Intel upstream saw the bug also https://github.com/luxonis/XLink/blame/e9eb1ef38030176ad70cddd3b545d5e6c509f1e1/src/shared/XLinkDispatcher.c#L420

[diablodale]

I've see alternate pthreads solutions for timed waiting which can use MONOTONIC clock as discussed https://stackoverflow.com/a/29153526. These would likely work on the non-Windows platform. Windows has os apis that can do similar. That leaves the OAK device itself...of which I don't know its os/runtime capabilities.

Since the device has its system clock constantly sync/changed to match the host, this could be a source of occassional random device errors if a device is preparing/processing a wait while its clock is changed due to sync with host. Only a device developer can understand if this is a problem since that code is closed-source.