Quoting folkert <folk...@vanheusden.com>: :
+127.127.28.1 .PPS. 0 l 4 8 377 0.000 2.231 0.005
:
I'm surprised that the jitter goes down to 0.005 as I'm now measuring the PPS from userspace. My program runs with "real time" scheduling and maximum priority but still the kernel needs to do a context switch etc. when it receives the pps pulse.
I got similiar results with measuring the PPS timestamp in a userland real-time (SCHED_RR) process. All my hardware is different from yours, but it sounds like our software is close in architecture. Here's the graph of jitter over two days: http://dan.drown.org/stm32/run5/time-variance.png
I'm using the setting "minpoll 4 maxpoll 4" for a 16 second cycle and sending the median of those 16 offsets to ntpd. I'm also collecting the max and min offsets, and graphed them here: http://dan.drown.org/stm32/run5/usb.png
As a comparison, I tried timestamping in the kernel and put the min/max graphs for kernel vs userland side by side: http://dan.drown.org/stm32/run6/usb-compare.png
The jitter for the kernel timestamping run is improved as well: http://dan.drown.org/stm32/run6/time-variance-compare.png
More info on the userland/kernel comparison: http://dan.drown.org/stm32/run6.html
_______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
