Timestamp precision

[scrupeus]

Just wondering why the interrupt timestamps are struct timeval rather than struct timespec? (i.e. microsecond rather than nanosecond precision) See pps_interrupt1 for example.

Wouldn't a nanosecond timestamp reduce quantisation noise? I appreciate the client code would need changes but I can't see an obvious reason for using microsecond precision.

[scrupeus]

I forgot to add... You can use getrawmonotonic to get monotonic time with nanosecond precision in a kernel module. I'll also add that I'm not a kernel dev and there may be a better/preferred function to use!

[rascol]

The original design philosophy for pps-client was to synchronize to the PPS without bypassing NTP simply because it might be the only available way to get whole seconds. That required using adjtimex() which contains the NTP time adjustment algorithm. Unfortunately, adjtimex() only knows about time to an accuracy of microseconds. So nanosecond precision would be rounded to microseconds anyway.

[scrupeus]

Using nanosecond precision would reduce noise in your calculations and potentially affect the required adjustments (some may be eliminated, others may be added). But I agree it wouldn't be a big improvement.

Checking man adjtimex, nanosecond precision is enabled by including ADJ_NANO in the modes field. I also noted that the comments in timex.h for struct timex are misleading by only mentioning microseconds, but ADJ_NANO is in the header.

Please note that I'm not suggesting you (or anyone else) necessarily change the code to use nanosecond precision; not much more would be gained with the current code. I was just curious as to why the decision had been made, which you've answered.

[rascol]

Thanks for the catch. I was unaware that adjtimex() could be extended to nanoseconds. At some time in the future that would help in a redesign. But as long as clock stability is on the order of a few microseconds and Linux interrupt latencies are even longer, that isn't in the game plan.