[ntp:questions] Re: Reference Identifier

David L. Mills mills at udel.edu
Mon Aug 4 14:47:14 UTC 2003


See below.


Morpheus wrote:

>>Please see the spec again and note the difference between the reference
>>identifier and reference timestamp fields.
> i'm really sorry but i don't understand... :(
> in the specs, RFC 2030 SNTPv4, we find:
> *Reference Timestamp: this is the time at which the local clock was set or
> corrected, in 64-bit timestamp format.
> -> this means that server synchronize with "something" (via another NTP
> server or an external reference) and if it has to correct its clock that
> was the time when it indeed corrects its clock: am i wrong?

Please see RFC-1305 for a detailed explanation. Read the statement 
exactly as it says. Nothing more, nothing less. The reference timestamp 
is the time the local clock was last set by whatever means. It has 
nothing to do with offset/delay calculations. Period.

> *Reference Identifier: NTP server v3-4 stratum 0-1 it is an ASCII string;
> NTPv3 secondary server, it is the IPv4 address of the reference source;
> ###NTPv4 secondary server it is the low order 32 bit of the latest transmit
> timestamp of the reference source###
> -> the ###...### part is the one which i don't understand... are you talking
> about the second half of the NTP timestamp (ie the fractional part)? if so,
> but of which timestamp? the last update of the local (server) clock?

Again, see RFC-1305 for detailed explanation or, for that matter, 
RFC-2030 which you quote. The IPv4 reference identifier is exactly as 
specified therein. The IPv6 reference identifier has been modified. See 

> From what i've understood, Ref ID is not a timestamp but is just a part of a
> time stamp (which??) and analizing the packets it is NOT the integer part
> of a time stamp (seconds) because of the first byte of the now-day NTP
> timestamp is 0xc2 which is not the first byte of the RefID (which is varing
> very fast) so i suppose this is the fractional part (fractions of seconds)
> of the last update of the local (server) clock due to synchonization with
> its reference source. is it right?
> Thanks for your time and help!

More information about the questions mailing list