In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Brian Szmyd) wrote:
> We have a customer using our product running SNTP v4 and they have SNTP is not NTP and one can expect SNTP implementations to drift by the full clock frequency error between polls. > having trouble keeping the machine in sync with their v3 NTP server. Obvious question: have they actually told the client to use the down version (obsolete) version 3 protocol? > They are seeing a drift of about a minute a day...and I really have no A minute a day exceeds the capture range of the full version 4 NTP implementation. Whilst SNTP might not care about this, it indicates the client and/or server are running on broken hardware or the one that is slow is losing clock interrupts. If the server is using a broken source of time (as it looks like it is) the drift error could be split between client and server. You should aim to fix the hardware so that the error is no more than about 20 seconds a day, although 3 seconds would be more realistic for good hardware. (20 seconds is something like the worst from cheap, but working, hardware. A full, version 4, ntpd can cope with a machine with an error of about 43 seconds, a day, but really needs some safety margin, and this is worse than I have seen for unbroken hardware.) > If I look at the Frames under Ethereal I see: > .... > Clock Dispersion: 10.2222 sec This is incomplete and doesn't use standard terminology. I assume that this is Root Dispersion, in which case the server is indicating that its time is so broken than no standard implementation will touch it. Root dispersion is an estimate of the maximum accumulated error since a real reference clock was read. I believe that the protocol shuts down when it reaches one second. If you had all the parameters, you might find other fault indicators. > Reference Clock ID: uncalibrated local clock This almost certainly indicates an unsupported configuration. NTP should always have ultimate recourse to a reference clock that is locked to true UTC. > Reference Clock Update Time: May 4, 2006 08:52.53.0510 UTC This indicates the last time at which the packet sender updated its clock from an upstream source. This is weird, as one of the things about using the local clock reference is that it pretends that the time was set accurately every 64 seconds, even though it can be completely bogus. I wonder if this is not really an NTP server at all, but one of the original, broken, Microsoft SNTP servers. One thing I believe that can do is to reflect back the client's root delay and dispersion. > Originate Time Stamp: May 4, 2006 13:50:18.8941 UTC This is the time at which the other machine last sent to the current sending machine, using its idea of the time. > Receive Time Stamp: May 4, 2006 13:50:18.3950 UTC This is the time at which the current sending machine received the packet to which this is a response. > Transmit Time Stamp: May 4, 2006 13:50:18.3950 This is the time that it sent the response. > Clock Dispersion: What is this? Probably Root Dispersion. See RFC 1305. > Ref. Clock ID: " > Ref. Clock Update Time: I assume this is the time that this server was > last updated? > Originate Time Stamp: Meaning? > Receive Time Stamp: " > Transmit Time Stamp: Time the packet was transmitted? These are all basic NTP concepts described in RFC 1305. > Do these fields have different meanings in the context of Client to > Server and vice-versa? The protocol doesn't clearly distinguish between client and server, although an SNTP client can't, I think, use one of the symmetric modes. However, request Transmit becomes response Originate. > Which fields should be closing the gap and what If you are using SNTP with a simple clock discipline algorithm, the values should always reflect the drift of the client since the last poll, so should not be closing when properly synchronised. > does it mean to have them actually drifting apart? The Polling Interval > is 6 seconds if that is of any value. That is extremely fast! 500ms in 6 seconds is so far over the maximum plausible drift rate that it is reasonable to assume the server is being ignored. If the figure quoted, is Root Dispersion, that should be sufficient for it to be ignored, but I suspect it may well be showing an alarm state and stratum 16 as well (if it is showing stratum 2, that is almost a guarantee that it is not NTP, but rather W32Time's broken SNTP). Note, if you used a real NTP client, it wouldn't poll more often than every 64 seconds, by default, and would typically poll every 1024. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
