Day changed to 2026-02-02
[22:51] jfw: I think I've found the right cut for the timekeeping knot on my Gales machines, which so far have had freely & significantly drifting clocks, while I still set my watch from a legacy system running the bloaty and bug-ridden ntpd
[22:53] jfw: I'm porting djb's "clockspeed" which basically serves to calibrate the PC quartz under its actual operating conditions, squeezing as much accuracy as possible from the commodity reference
[22:55] jfw: unlike djb's usage, I won't attempt to track TAI with the attendant complexities and compatibility nightmares of translating that to UTC in userspace (or perhaps even kernel space)
[22:59] jfw: but unlike ntpd, I won't attempt to follow the present definition of UTC, this sort of hybrid monster which ticks in sync with TAI but jumps unpredictably in "leap seconds" to resync with the earth's rotation
[22:59] jfw: instead I can simply get my clockspeed adjustment samples from the NIST UT1 time server
[23:00] jfw: no leap seconds
[23:00] jfw: <1s offset from UTC
[23:01] jfw: it fluctuates relative to atomic time, but not to a perceptible degree on the available hardware
[23:06] jfw: if money's not an issue, it's just as objective & independently verifiable as atomic time: one is just based on astronomical observations while the other's based on atomic observations. and without the practical means or need to make those myself, it's just a tossup between tuning into one or another signal from authority
[23:09] jfw: but the re-syncing to that outside signal is an occasional, deliberate thing that can be sanity-checked, *not* a slavish acceptance
[23:11] jfw: if someday I find myself with an actual need for a cesium clock, I expect I'll also have the means to tweak the software, re-derive my own UT1 if needed and so on.
[23:19] jfw: philosophically, this bases computer timekeeping on the reference where it arguably belongs - the sun, the very fundament of life on earth and regulator of the human organism, that which we supposedly created the computers to serve. rather than the technically and scienterifically more accurate basis nonetheless far removed from human experience or care.
[23:33] jfw: while djb also invented a "taiclock" protocol to serve his preferred standard, I couldn't find any actual public servers for it; looks like a lost cause to me. so of the available options, this one looks by far the most appealing. "check in on my UT1 delta" fits better in my quarterly calendar than "check for new leap seconds, recompile the .dat file, then check in on my TAI delta"
[22:51] jfw: I think I've found the right cut for the timekeeping knot on my Gales machines, which so far have had freely & significantly drifting clocks, while I still set my watch from a legacy system running the bloaty and bug-ridden ntpd
[22:53] jfw: I'm porting djb's "clockspeed" which basically serves to calibrate the PC quartz under its actual operating conditions, squeezing as much accuracy as possible from the commodity reference
[22:55] jfw: unlike djb's usage, I won't attempt to track TAI with the attendant complexities and compatibility nightmares of translating that to UTC in userspace (or perhaps even kernel space)
[22:59] jfw: but unlike ntpd, I won't attempt to follow the present definition of UTC, this sort of hybrid monster which ticks in sync with TAI but jumps unpredictably in "leap seconds" to resync with the earth's rotation
[22:59] jfw: instead I can simply get my clockspeed adjustment samples from the NIST UT1 time server
[23:00] jfw: no leap seconds
[23:00] jfw: <1s offset from UTC
[23:01] jfw: it fluctuates relative to atomic time, but not to a perceptible degree on the available hardware
[23:06] jfw: if money's not an issue, it's just as objective & independently verifiable as atomic time: one is just based on astronomical observations while the other's based on atomic observations. and without the practical means or need to make those myself, it's just a tossup between tuning into one or another signal from authority
[23:09] jfw: but the re-syncing to that outside signal is an occasional, deliberate thing that can be sanity-checked, *not* a slavish acceptance
[23:11] jfw: if someday I find myself with an actual need for a cesium clock, I expect I'll also have the means to tweak the software, re-derive my own UT1 if needed and so on.
[23:19] jfw: philosophically, this bases computer timekeeping on the reference where it arguably belongs - the sun, the very fundament of life on earth and regulator of the human organism, that which we supposedly created the computers to serve. rather than the technically and scienterifically more accurate basis nonetheless far removed from human experience or care.
[23:33] jfw: while djb also invented a "taiclock" protocol to serve his preferred standard, I couldn't find any actual public servers for it; looks like a lost cause to me. so of the available options, this one looks by far the most appealing. "check in on my UT1 delta" fits better in my quarterly calendar than "check for new leap seconds, recompile the .dat file, then check in on my TAI delta"