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

Christopher J. Holland msnews at microsoft.com
Tue Aug 5 00:08:10 UTC 2003


David,

>I assume you have seen the errata at  www.ietf.org.
No. I haven't.

>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
That is what I am trying to do.

If I needed something simple, I would use  the Daytime Protocol,
or 32 bit number in the Time Protocol.

> Is the game over now?
What game?

I'm not a TCPIP guru. I am just in the learning stage if you can't tell.
I can't seem to get an answer from you. All I get is sarcasm.

Regards,
"David L. Mills" <mills at udel.edu> wrote in message
news:bgkink$c8v$1 at dewey.udel.edu...
> 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