On Thu, Oct 15, 2020 at 2:13 PM Helmut Grohne <helmut.grohne@xxxxxxxxxx> wrote: > > On Thu, Oct 15, 2020 at 01:43:32PM +0200, Bartosz Golaszewski wrote: > > Well, it's a long story. It used to be what the kernel calls REALTIME > > clock, then it was changed to MONOTONIC and now there's a suggestion > > to make it configurable in v2. More on that here[1]. > > Ouch. I was wodering already as the timestamps looked like REALTIME > here, but I'm simply using an older kernel. In that case the type of > your timestamps should depend on the Linux kernel version, which is > impossible to do. All you can do now is lie for older kernels. > The library doesn't define what the timestamp is really and so doesn't guarantee anything either. This will change in v2 as we'll make this clock configurable so we'll have to define that by default the clock is MONOTONIC and can be explicitly changed to REALTIME. > > One question is: even if on linux the steady_clock is backed by > > CLOCK_MONOTONIC, is this a guarantee or just implementation? And can > > we rely on this if it's not defined? > > Like the nanosecond resolution of steady_clock this is certainly not > guarantueed. However, it is rooted so deeply that it is very unlikely to > change. In theory, there could be a chance of changing it to > CLOCK_BOOTTIME. I don't think anyon is going to try. > > At this point I recommend going with steady_clock. > > Helmut Ok, will do. Bartosz