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
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.
Throughout depthai-core and Xlink I believe
CLOCK_REALTIME
is wrong. It should beCLOCK_MONOTONIC
but there is a problem in POSIX's semaphore API. 😕The code everywhere is relative time when
CLOCK_xxxx
is used with apis likeclock_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 elseChanging 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.
The text was updated successfully, but these errors were encountered: