"Terry Moore" <tmm%mcci.com@localhost> writes: > If the time info is presented into NTP using the same interface that network > packets use, then jitter will be pretty well damped (and will be less, in > any case, than typical network packet transport jitter). It is totally an > application question as to whether this is good enough. I was assuming that, > since the jitter on local interrupts is much less than on network packets, > that there might be a different PLL tracking the data, as there are lots of > tradeoffs here. But if it works well, by all means use it. ntpd seems to have adaptive means to decide how to cope, and this is pretty well shaken out. It switches from PLL to FLL. It's fair to be skeptical here, but it's easy to get carried away, as it's infrequent to get ms-level accuracy synchronzing across other than a local network. > And I know Mouse is more careful than I tend to be about terminology and so > forth; he is, if I understand correctly, arguing that PPS directly connected > is a lot different than PPS over USB, and so should be called something > else. I don't have an opinion on that. But PPS means "pulse per second", which refers to the signal before it enters the computer. There's a standard "Pulse-Per-Second API" that is agnostic with respect to connection means. It doesn't mean "PPS connected over serial with very small interrupt latency", even though that's the conclusion many jump to. > I believe that for critical > applications you'll get much less jitter using PPS directly connected; but > I'd have to do experiments and my day job calls.... I think you're totally right on that point, and I didn't mean to suggest otherwise.
Attachment:
pgpel28D9IGIy.pgp
Description: PGP signature