In article <[EMAIL PROTECTED]>, Richard B. gilbert <[EMAIL PROTECTED]> wrote: > edouard funke wrote:
> > - change OS (again what is the impact ?) > Some operating systems keep time a little better than others. Windows > and Linux have both been known to lose clock interrupts during periods > of high disk usage. I've had good results with Solaris (8, 9, & 10) but > others here seem to have had results differing from mine! Also, Windows, in default configuration, will only provide a resolution of about 15 to 20ms (whatever the clock interrupt rate is) in the times provided to application programs. ntpd plays tricks to make its own times more accurate, and therefore the phase of the system clock more accurate, but, in my experience, that breaks down when the system is heavily loaded. It is possible that enabling multimedia timers will improve the resolution of time supplied to application programs; I haven't tested this. However, I would think that the probability of lost interrupts will be increased. It's absolutely essential that you do not change the enablement state of these timers, as the transition causes a shift in the time seen by ntpd. > > is the accuracy of a millisecond "achievable" in those conditions ? If > > not, what can i do to achieve it ? > Without a UTC reference (hardware reference clock or at least one (four > or more are best practice) internet server) your clocks WILL drift. > They may drift badly. Synchronization between systems may be fairly > loose (many milliseconds difference between different machines). I imagine he is only concerned about the synchronisation between machines. Especially with a TXCO, that should be better than WAN sourced time, because there will be little network jitter. They will drift in relation to true time, but ought to keep together well, as long as there isn't too large an offset between server and client natural clock frequencies. However, for a high percentile of system times being within 1ms of the reference, he probably should be using PPS timing with equal length cables between the timing source and all the machines. Note that no-one can guarantee a 100 percentile <1ms performance. One other factor to bear in mind is that time is of no use without some real world event to time. Interrupt latencies or polling delays for the device drivers that capture those events may also compromise the 1ms. The reason that both Linux and Windows lose interrupts is that they have interrupt latencies longer than the chosen clock tick (especially if Linux tick gets set to 1000Hz (1ms). > The 20 millisecond network delay between buildings seems excessive and > may cause problems. The maximum error in transmitting time from server That certainly rings alarm bells. One really needs to know much more about the technology involved. Only if the delay were purely the result of using an analogue delay line (which is a silly suggestion), in both directions, would it not affect timing. What matters is any asymmetry, and the uncertainty in the delay from packet to packet. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
