[ntp:questions] Re: on calculi for delay & offset

David L. Mills mills at udel.edu
Mon Aug 4 03:08:32 UTC 2003


Christopher,

Your site quoth RFC-2030; I assume you have seen the errata at 
www.ietf.org. You have consistently misinterpreted that RFC and, as I 
suspect, have not seen or understood the briefings I suggested you light up.

The basic protocol suggested in RFC-2030 does not require the client to 
provide any timestamps at all, since really simple implementations might 
not want to go to that trouble. However, if you do need to calculate 
more precise offset and delay, then you do have to include the 
timestamps and process them as described in the RFC.

Is the game over now?

Dave

Christopher J. Holland wrote:

> Hi,
> 
> 
>>i was thinking about this: an SNTP client sends a packet with all bytes
> 
> set
> 
>>to 0 but the first one, so every timestamp is set to 0.
> 
> You send the Originate Timestamp and the 3 other 64 bit timestamps are 00's.
> 
> 
>>Now, when the client comes to calculate the delay and the offset it needs
> 
> the Originate
> 
>>Timestamp (which, it's known, is copied by the server from the packet
>>recieve) but, hey, where is it? It has no valid Originate Timestamp...
> 
> Yes it does.
> The Originate TimeStamp was sent by you in the First Packet.
> My guess is that the server just copies it and sends it back to you.
> Maybe they plan on doing something with it?
> 
> 
>>The conclusion is: if the client wants to calculate the delay and the
> 
> offset
> 
>>it has to send a packet with a valid timestamp and it doesn't want those
>>results it can send a packet fill with 0 except the first. Am i right?
> 
> Well, you should go ahead and send the Timestamp, since that is what the
> protocol calls for.
> 
> See if this help.
> http://24.25.205.51/Project_TCPIP/Project_NTP/Project_NTP.htm
> I'm close to figuring the protocol out.
> 
> HTH,
> "Morpheus" <spam at world.com> wrote in message
> news:UIdXa.15206$an6.551919 at news1.tin.it...
> 
>>Hi,
>>i was thinking about this: an SNTP client sends a packet with all bytes
> 
> set
> 
>>to 0 but the first one, so every timestamp is set to 0. Now, when the
>>client comes to calculate the delay and the offset it needs the Originate
>>Timestamp (which, it's known, is copied by the server from the packet
>>recieve) but, hey, where is it? It has no valid Originate Timestamp...
>>The conclusion is: if the client wants to calculate the delay and the
> 
> offset
> 
>>it has to send a packet with a valid timestamp and it doesn't want those
>>results it can send a packet fill with 0 except the first. Am i right?
>>
>>thanks again
> 
> 
> 




More information about the questions mailing list