It really bugs me how often ntpd produces slightly out of sync clocks by trying to be overly clever with skew and with trying to not break software that relies on a monotonically increasing clock. If something breaks when the clock fails to increase monotonically, it's shit, I don't care if it crashes. I'd rather it crash so that I know to uninstall it.
So, I tried to do it "right" this time, but I am going with the strategy that works: run ntpdate pool.ntp.org after the net comes up and then periodically run it again from a cronjob. ntpd(1) has some warnings about how if you do it that way, you don't get the cool skew detection, and it should be the opposite
In other news, cargo is a total piece of shit and this should come as no surprise to me because Rust is a language made by children that have no idea what they're doing but every time I have to interact with software written in Rust, the compiler and the tooling find new ways to disappoint me. I should just get a bunch of RISC-V gear so Rust shit won't run and I don't run into problems like this. boxesallinarow.png
@p Like cargo just thinks REALTIME should only ever increase similarly to MONOTONIC?
Shit really ought to crash, although I could see that causing cases of data corruption.
@istvan@p Does endianness matter? I have a Powermac G5 laying around but that can only run big-endian binaries. (I guess I can check Chimera's package search on the matter)
@istvan@allison Oh, holy shit. I remember that kernel option to swap the framebuffer's endianness, I bet it was for avoiding running the whole box with the endianness swapped.
@p@syzygy I think by default chrony sets the clock at launch and then drifts.
At least if I'm reading the manpage right, here with makestep 0.1 3 (which is given in the manpage, hence my guess of me not modifying the config) it adjusts by steps of 0.1 seconds unless it's bigger than 3 seconds.
@p@syzygy Which I'd say is the correct behavior, 3s being RTC drift over quite a long period of time, more than that and your clock is likely entirely off.
> I think by default chrony sets the clock at launch and then drifts.
Yep, this is what the docs indicate, this is exactly the behavior I want (and apparently they use the ethernet hardware timestamps). ntpd tries to guess at and anticipate drift and then jump to the target time in 250ms increments. As far as I can tell, it has never done that correctly, or those clocks would get closer together rather than one of them speeding up and one slowing down.
> it adjusts by steps of 0.1 seconds unless it's bigger than 3 seconds.
Add comment