> No, that description only holds for what are called "coarse" clocks.
Do you understand this area? I think the term I've been missing is "dither". I don't understand that area well enough to explain it to anybody. Interesting timing. I was at a talk a few weeks ago that covered dithering. The context was audio processing and I wasn't smart enough to notice the NTP connection. --------- The idea with dithering is to add noise in bits below what you can measure. There are several interesting quirks with the current code. There isn't a sensible way to measure the step size of the system clock. The current code fuzzes below the time to read the clock. That has nothing to do with the clock tick size. It's just a pipeline delay. And the time-to-read that it uses includes lots more than just raw reading the clock: 150 ns vs 30 ns on a reasonably modern Intel CPU. You can see the actual clock step size in the histogram output of attic/clocks I'm not sure how to automate that. I haven't studied what ntpd does with coarse clocks. I don't have a sample to test with. The step size on Intel HPET is ~70ns. The time to read it is 500-600 ns. Step size on an Pi 1 is 1000 ns. ~50 ns on a Pi 2 and Pi 3. With the current code, get_systime() is fuzzed. It's called from quite a few places. The only ones that need fuzzing are the ones used for timekeeping. There are only 2 of those, one for sending requests and the other for sending replies. The 2 packet receive time stamps don't get fuzzed. Neither do the PPS time stamps. There are several calls in the NTS code - just measuring elapsed times to do KE. The API is convenient. We should setup something to avoid fuzzing. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
