[EMAIL PROTECTED] wrote: > I just want to clarify something. ntpdc can be used to check on the > offset from the peer, right? What is the smallest offset in clocks
You cannot find out the offset from the peer; to do that you need to synhronise an independent clock to an order of magnitude better, then read the two software clocks relative to that alternative time synchronisation mechanism. The value you get for offset is the difference between a smoothed estimate of the true time, based on measurements over an extended period, and an average of the most recent measured times from the active servers. The latter should contain a lot more measurement noise than the former. > that I can expect on a 1 Gbps LAN? Depends on interrupt latency, network loading, the total lack of any Windows machines in the time synchronisation chain, etc. 100ns should be possible for lightly loaded machines on a lightly loaded network, at least 90% of the time. However, my feeling is that the only acceptable solution in your case would be to feed a pulse per second signal into a PCI or ISA connected serial or parallel port (not USB) from the same line driver. You will need an OS with kernel PPS support. To use 100ns timing in your applications, you will need an OS and hardware that support a timing source with maybe 10ns resolution. This excludes Windows and any OS more then about 3 or 4 years old. Note that broadcast mode will be critically dependent on the initial calibration exchange. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
