In article <[EMAIL PROTECTED]>, Richard B. Gilbert <[EMAIL PROTECTED]> wrote: > Eric Liu wrote: > > Subject: Ntpd accuracy
This is misleading, because it is clear that you don't want accuracy but simply that all machines have the same error. > >server 192.168.0.121 minpoll 4 # The dell computer is time server You shouldn't override minpoll, especially if you are using Windows as a server, as you need a reasonably long poll interval in order to properly average the sampling variations, as noted below. > >We can see that the offset varys in a very large range. How can I make the Offset is not the same as the time error, and is generally larger than that. > > Your largest offset is 23 milliseconds (absolute value) which is not > bad for a machine synchronized to a server using its local clock as a > reference. The local clock on virtually any computer will not It's not bad for a machine synchronised to loaded Windows system. Unless temperatures are varying wildly, the second order (df/dt) variations in computer clocks really aren't that bad. The static frequency error is likely to be high, but all the machines in this isolated system are working with the same false idea of time and frequency so the static errors don't matter. (If the questions here reflect the real use of ntpd, it is no longer used for its intended purpose, but simply for measuring small time differences between the components of isolated systems.) However, in my experience, Windows is vulnerable to large scheduling delays, of the order of 10 to 20ms, so if ntpd is run on a loaded machine you can expect sampling variations of the order of the scheduler time slice. Once scheduled, ntpd interpolates between clock interrupts and gives a more accurate time, but that is not available to clients. If it is synchronised to an external clock it will average out its measurement errors, and it will trim the local clock so that the time is very accurate on an interrupt. However, external queries are subject to scheduling and packet queueing delays. Local applications on the Windows box will only see time to a resolution of 10 to 20ms, anyway. The other problem that Windows has is losing clock interrupts - I suspect, given the way that it slowly recovers, that the -23ms error is a lost interrupt. Something that should be borne in mind, though, is that, apart from lost clock interupts, the ntpd loop filter on the clients will tend to smooth out the sampling errors, so that the client machine clocks may well be much closer to representing the same linear function of time than the reported offsets imply. Even when there is a lost interrupt, the clients may well respond to it in the same way, so track together. If he wants 1ms accuracy, even assuming he only needs that accuracy over total intervals of 10s of ms, he needs to analyse the client machines for interrupt and scheduling latency. There is no point in having 500 micro second clock accuracy if you are timing external events and disk interrupt processing can delay them by up to more than 10ms. > The situation is analogous to one drunken driver trying to follow > another! The server's clock drifts but the client assumes that the The distance beteen the two tailgating cars may actually be relatively constant. He's probably not interested in how far they are from the kerb, or how far they have travelled, but only the bumper to bumper distance. > The fix is to use a stable and accurate reference for the the server. This may make things worse for this, increasingly common, abuse of the NTP protocol. If the server is trying to track an upstream server or a reference clock it is going to hunting around the correct time, whereas letting the local clock free run will give neither true time nor frequency, but the clock phase will advance very uniformly with real time, which is all you need for measuring small time differences. In his situation, he should dedicate one of the PC104 machines to being the pseudo-time server. Ideally he would use the timed protocol, which is intended for his sort of usage, but that isn't widely available. The PC 104 server will be unloaded and won't be running Windows. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
