On Thu, 2023-12-28 16:35:40 +0100, Jan-Benedict Glaw <jbglaw%lug-owl.de@localhost> wrote: > On Thu, 2023-12-28 06:38:52 -0500, Ken Wellsch <kwellsch%tampabay.rr.com@localhost> wrote: > > I do hope you do find an issue, that is a virtue of a community project > > with open source. I am only one data point trying to see whether I can > > reproduce the issue. My geographic location, home network and ISP > > connection are uniquely my own and what works for me, over less than > > one day of testing, is definitely not enough testing. > > As I'm now running idle with ntpd enabled (and a frequency of ~ +40), > my observation is that initially, it was fuzzy and lost sync several > times, but it seems to be stable by now. > > Maybe I'd restart and delete the drift file, just to see if it's > that volatile again right at the start? For the time being, I'm > building a ntpd that syslogs a message whenever the ieee fp code is > used. Maybe we have a situation like ... that's initially used, but > not usually after it established a good sync? I've done a few rounds of experiments. `ntpd` seems to work fine on this /60. Startup may be a bit sluggish, but it finds its peers and syncs fine, as does ntpd on some amd64 Linux box. Also, it seems the ieee754 functions aren't actually used. (Added some logging and that doesn't ever show up.) My result so far is that the 4000/90 as well as the /60 seem to properly keep time on their own (with a drift of some two to four seconds per day) and ntpd is capable of managing that. A bit on the odd side: It seems to not extend the poll interval beyond 128sec for useable peers, and I've (at max) only seen 256sec once for a claimed falseticker. OTOH, the amd64 Linux box will extend to the 1024sec interval soonish. (It seems the amd64 box stays *very* long with a specific pll freq, whereas the VAX systems keep adjusting it by minute details. I guess that's a related fact.) MfG, JBG --
Attachment:
signature.asc
Description: PGP signature