| raw e-mail | index | archive | help
I also have an incomplete patch that adds support for clock_gettime(3) using
PHC fds as clockid_t values, but since it isn't complete I'll keep it to
myself for now :)
So, that's what I've been up to. As I said in the beginning, I wanted to
get more of this done, but I think it makes sense for me to let others know
about my code now.
I plan to continue hacking away on this, but if people have opinions about
any of this, I'd love to hear them. It really pains me that there is so
much duplication between the PHC and timecounter code, but the current
tc_windup code runs in a rather special context (hardclock) and having it
process *all* devices regardless of use would increase its runtime quite a
bit. I've been thinking about trying to move some of the timecounter and
PHC code into a generic set of helpers or try to reorganize kern_tc.c to
fold the PHC login into it sanely, but that's currently very far down the
todo list.
To summarize, the goals/non-goals for this work are:
Goals:
* read-only interface to various precision hardware clocks (PHCs)
* support for both absolute time and counter-only PHCs
* ability to use software like chrony to stabilize system clocks
Non-goals/future work:
* adjusting PHCs
* support for cross-timestamping techniques (like Intel's ART)
* support for if_em PTP packet timestamping
* external pin timestamping support
Thanks for reading this far. Let me know if you have any questions,
suggestions, etc.
Jeff.
[1] I actually ran for about a week with a e1000e card in my box providing
timekeeping by selecting it via the kern.timecounter sysctls. It worked
and was quite amusing to see, but the additional complexity in tc_windup
made it unworkable.
[2] At some point, Intel added the Always Running Timer (ART) which can be
used by devices to get timestamps that are easily convertible to TSC
readings. Support for this is part of future work.
[3] The chrony config was the following. I ran chronyd with the -x flag to
prevent it from trying to set the clock. The system clock was
disciplined with ptp2d, which was syncing to ptp2d running on the same
server that chrony used for NTP. Note that the refclocks are marked as
'pps local', meaning that they are to be used only as a frequency
source. ('pps' means that the refclock isn't reporting UTC, and 'local'
means that the clock isn't aligned to UTC seconds)
server <server> iburst minpoll 0 maxpoll 4 xleave
refclock PHC /dev/phc-em0 refid EM0 pps local
refclock PHC /dev/phc-em1 refid EM1 pps local
logdir /tmp log measurements statistics tracking refclocks selection rtc
logbanner 0
[4] https://mastodon.radio/@jeffpc/112230743393202103
[5] A huge problem with NTP is that it suffers greatly from any network
latency jitter and asymmetrical routing. Having a stable reference
clock (even if the stability is short-term only) helps NTP software
quite a bit.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?>