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
We have evidence that CLOCK_MONOTONIC can go backwards on macOS. We have a device running macOS 14.6.1 and it seems to have a slightly defective clock. (There are lots of multi-second time jumps in the logs, especially around sleeps.) It appears that this triggers a bug in macOS that causes CLOCK_MONOTONIC to occasionally jump.
Short term clock jumps may cause issues with WireGuard, one major issue I am aware of is triggering something like NordSecurity/boringtun#8 on a forward jump which would trip a rate limit and break the connection.
There seems to be no perfect clock on macOS. For the use cases here the ideal monotonic clock would have no discontinuities and prioritize short-term accuracy. From man clock_gettime, CLOCK_MONOTONIC seems to provide long-term accuracy and it is implied that it allows time jumps (even though that would be a POSIX violation). CLOCK_MONOTONIC_RAW provides neither short-term or long-term accuracy but disallows time jumps.
In our opinion preventing jumps is likely the better trade off for NepTUN, as IIUC clock rate accuracy doesn't matter until you get around 0.5x or 2x rate difference. However clock jumps can break your tunnel.
Another consideration may be CLOCK_MONOTONIC_RAW_APPROX which is supposedly cheaper but "it may return values that are milliseconds old". However this amount of staleness is likely acceptable for the WireGuard use case as we are talking over a network where things likely have a few milliseconds of jitter anyways.
The text was updated successfully, but these errors were encountered:
Quick question: maybe You had a chance to investigate how CLOCK_MONOTONIC_RAW is behaving in presence of sleeps? E.g. if process running NepTUN is put to sleep for some amount of time, or even if full device is put to sleep - after wakeup - does it indicate the time which has passed during the sleep?
I am asking, because this behavior is rather important for recovering WG session after prolonged sleep periods.
CLOCK_MONOTONIC_RAW should have the same behaviour as CLOCK_MONOTONIC with regards to sleep. Here is a snippet from man clock_gettime which I think explains it:
CLOCK_MONOTONIC_RAW
clock that increments monotonically, tracking the time since an arbitrary point like CLOCK_MONOTONIC. However, this clock is unaffected by frequency or time adjustments. It should not be compared to other system time sources.
We have evidence that
CLOCK_MONOTONIC
can go backwards on macOS. We have a device running macOS 14.6.1 and it seems to have a slightly defective clock. (There are lots of multi-second time jumps in the logs, especially around sleeps.) It appears that this triggers a bug in macOS that causesCLOCK_MONOTONIC
to occasionally jump.Short term clock jumps may cause issues with WireGuard, one major issue I am aware of is triggering something like NordSecurity/boringtun#8 on a forward jump which would trip a rate limit and break the connection.
There seems to be no perfect clock on macOS. For the use cases here the ideal monotonic clock would have no discontinuities and prioritize short-term accuracy. From
man clock_gettime
,CLOCK_MONOTONIC
seems to provide long-term accuracy and it is implied that it allows time jumps (even though that would be a POSIX violation).CLOCK_MONOTONIC_RAW
provides neither short-term or long-term accuracy but disallows time jumps.In our opinion preventing jumps is likely the better trade off for NepTUN, as IIUC clock rate accuracy doesn't matter until you get around 0.5x or 2x rate difference. However clock jumps can break your tunnel.
Another consideration may be
CLOCK_MONOTONIC_RAW_APPROX
which is supposedly cheaper but "it may return values that are milliseconds old". However this amount of staleness is likely acceptable for the WireGuard use case as we are talking over a network where things likely have a few milliseconds of jitter anyways.The text was updated successfully, but these errors were encountered: