In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Tony Rutkowski) wrote:
> For example, if the time-stamp included the > most recent NTP query information such as the This sort of information is available by diagnostic mode requests, but is generally blocked by anyone with a paranoid security consultant as revealing too much information about the server. > NTP reference clock URI, last local clock offset There is no URI scheme for reference clocks, but given that even a stratum 1 server may be using an average of the data from multiple reference clocks, I'm not sure that there is any meaningful value other than the already implied "UTC Time". The last clock offset should be statistically random, probably Gaussian and should be very much larger than the intrinsic error in the time on the server, so I'm not sure what real use it is. It may not be from the upstream source that has the greatest contribution to the server's estimate of the time, or, if one restricts it to that source, the relative weights of that source and another source might be something like 60:40, so it might cause a significant contribution to the time estimation error to be completely ignored. > and jitter, and current drift rate, much greater I had a feeling that something close to jitter was already transmitted, but I might be wrong. Drift rate is useless in this context unless you are monitoring how it changes from sample to sample from the same server, in which case jitter might be a better measure. Any drift rate between about -450ppm and +450ppm, as long as it is stable, indicates the server has no problems. > precisions could be effected. Any work being > done along these lines? Could you provide some concrete algorithms, and indicate why they couldn't be used, locally, by the server, to improve its own timekeeping. [ This article appears to be a thread root, but is threaded into a thread with at least two other articles. That thread is "Peering and synching with multiple interfaces and subnets". I'll truncate the References, but the damage has largely already been done, as newsreaders can chain the thread together with only one reference per article. Anyone who has killed the other thread won't even see this one. ] > References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
