Karl Denninger wrote: > Karl Denninger wrote: > >> Jason Rabel wrote: >> >>> What OS are you running, and what CDMA modem are you using? (Just >>> curious) >>> >>> Also from the info you gave it looks like it is using your CDMA >>> source, but >>> seeing the stratum at 16 I don't think you have had NTP run long >>> enough to >>> adjust the clock into sync. >>> >>> Jason >> >> >> >> FreeBSD 6 (and 7; I have both here); the modem is a Multitech MTCBA. >> > > Quick update on this.... it appears that while the timecode is being > stuffed appropriately, the underlying NTPD daemon doesn't like it - > after a half-hour or so (running with debug turned up) and watching it > log things, it fails to lock on and resets the time source, dropping and > restarting the clock. > > I assume this means it is unable to get "happy enough" with the > stability of the timestamps to formulate a "solution", declares the > clock "broken", and then restarts....... yes? > > The obvious question is "can a time source that outputs only with 1 > second resolution and only when polled generate > sufficiently-high-quality reference time for the system to use it?" > > If the answer is "no", then the curtain needs to be drawn on this > attempt. If the answer is "yes", then I need to figure out how to > accomplish getting better input resolution I suspect - perhaps with a > helper application that polls at a higher rate of speed (e.g. several > times per second) and "stuffs" timecode events into the receive buffer > (e.g. via a named pipe or similar) >
Subject to correction by someone who knows what he's talking about the answer is not just "no" but "HELL NO"! The resolution of 1 second is a killer. This is going to make the jitter a function of exactly when each poll is received. I doubt that ntpd cares very much exactly when a poll is sent. If this device has a PPS output, it might be useable. . . . _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
