Hi Perry, >For log purposes, if you're down at the 2ms level you're probably utterly fine. Sure, 2ms still good IF it is 2ms.
Provided I was expecting way less than 1ms, if ntpstat is reliable I could stop here. One example, ms logs have 1ms "resolution" (short version, please bear with me), not sure about accuracy and events may be logged out of order so no big deal, 2ms is still plenty of precision. >Note that there really isn't anything wrong with wanting to do better for its own sake, but from an engineering requirements point of view, you've already succeeded. Thanks, of course asking here is to improve but what is puzzling me is the 2ms value. Is it the actual accuracy? Here it is another command output(ntptime): ntp_gettime() returns code 0 (OK) time e56974e6.38dfefc0 Sun, Dec 19 2021 10:07:50.222, (.222167714), maximum error 6000 us, estimated error 0 us, TAI offset 37 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 0.347 us, frequency -12.253 ppm, interval 1 s, maximum error 6000 us, estimated error 0 us, status 0x2001 (PLL,NANO), time constant 3, precision 0.001 us, tolerance 500 ppm, I don't see 2ms accuracy, it seems better(0.347 us?). _______________________________________________ time-nuts mailing list -- [email protected] -- To unsubscribe send an email to [email protected] To unsubscribe, go to and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] -- To unsubscribe send an email to [email protected] To unsubscribe, go to and follow the instructions there.
