Subject: Re: [ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamp location

From: "STUART VENTERS" <[email-masked]>
Date: Wed, 6 Feb 2008 11:24:13 -0600

Dave,

>>That's the beauty of it. Herbie and Sue don't care. The delays are still 
>>reciprocal and the fact Sue's delays are one packet longer doesn't matter.

Sadly, this grasshopper appears to have a misconception of what you mean when you say 'the delays are still reciprocal'.  (Or perhaps is having trouble drawing timelines or doing algebra.) Please help me understand where I strayed from the path.

If the 'the delays are still reciprocal' and the client and server clocks are aligned, then shouldn't the offset equation equal zero?

Regards,

Stuart

ps, From RFC-1305 section 3.4.4, setting i=4, offset = ((T2-T1) + (T3-T4))/2.
    From the example,   T2-T1 = T3-T4 = -(packet time)
    offset = -(packet time)

pps, My working definition for matching reciprocal delays was that 
     the propagation/queueing/transmission delay between T1 and T2 
     is the same as between T3 and T4.
     Where same means same sign and magnitude.
     (In the example, they appear to be same magnitude, but different sign.)

ppps, It's interesting that in this example, T2 happens before T1.
      Appendix H, section 8.4, says this can't happen in our universe.
      (Perhaps I should consider this clue further.)
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Wed, 06 Feb 2008 19:10:31 +0000

Stuart,

In the famous equation you cite, add one second on the path from t1 to 
t2 and a coresponding second on the path from t3 to t4. The additional 
second cancels out. offset = {[(t2 + D) - t1] + [t3 - (t4 + D)]} / 2

Dave

STUART VENTERS wrote:

> Sadly, this grasshopper appears to have a misconception of what you 
> mean when you say 'the delays are still reciprocal'. (Or perhaps is 
> having trouble drawing timelines or doing algebra.) Please help me 
> understand where I strayed from the path.
>
> If the 'the delays are still reciprocal' and the client and server 
> clocks are aligned, then shouldn't the offset equation equal zero?
>
>
> Regards,
>
> Stuart
>
>

---

From: "STUART VENTERS" <[email-masked]>
Date: Wed, 6 Feb 2008 17:55:47 -0600

Dave,

>>t2 and a corresponding second on the path from t3 to t4. The additional 

That does not compute.
  In your equation, D delays the receive timestamps (T2 and T4)
  In the example, D delays Sue's timestamps (T1 and T4)

I fear the question stack has pushed too deep to ever pop out to the original goal.
  (IE. Understanding why CP1 and CP2 are (or are not) a necessary part of the spec.)

73's,

Stuart
-.-. .-. -

ps, If anyone would like to call and help me understand, my office phone number is (256) 963-8719.
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 6 Feb 2008 17:16:57 -0800

Q:
Wasn't the original goal to assign an "instant in the NTP packet-receipt 
process" which would indicate the specific time represented in the 
packet-structure itself?

Todd
----- Original Message ----- 
From: "STUART VENTERS" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 06, 2008 3:55 PM
Subject: Re: [ntpwg] ntpwg Updated NTPv4 Protocol 
Specification/timestamplocation

---

From: "David L. Mills" <[email-masked]>
Date: Thu, 07 Feb 2008 02:55:56 +0000

Stuart,

I try again.

Let t1, t4 belong to A and t2, t3 belong to B. From A's point of view, 
t2 is late by D and t3 is late by D. Prestatus equationatus.

Dave

---

From: "David L. Mills" <[email-masked]>
Date: Thu, 07 Feb 2008 03:13:29 +0000

TOdd,

No, no, no... The goal was never, never even since the 1979 ancestor of 
NTP, to set the clock relative to the transport medium or any capture 
point of the packet in flight.

THE GOAL OF NTP IS TO MINIMIZE THE TIME DIFFERENCE BETWEEN THE CLIENT 
CLOCK AND THE SERVER CLOCK.

With due and kind respect, have you been reading my messages?

The current discussion about the boys and girls is not about defining 
capture points for the NTP PDU but to demonstrate some design goals and 
rules that the operating system and hardware can use to optimize the 
accuracy. For my part these are not an integral component in the 
specification; others may disagree. A discussion on these points might 
well become and appendix to the specification in the form of best 
practices, but the implementer can choose or not choose one or the other 
without violating the specification.

Dave

> Q:
> Wasn't the original goal to assign an "instant in the NTP 
> packet-receipt process" which would indicate the specific time 
> represented in the packet-structure itself?
>
> Todd
> ----- Original Message ----- From: "STUART VENTERS" 
> <[email-masked]>
> To: <[email-masked]>

---

From: "TS Glassey" <[email-masked]>
Date: Wed, 6 Feb 2008 19:29:04 -0800

sounds like we violently agree through different terms.

----- Original Message ----- 
From: "David L. Mills" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, February 06, 2008 7:13 PM
Subject: Re: [ntpwg] ntpwg Updated NTPv4 
ProtocolSpecification/timestamplocation

> CLOCK AND THE SERVER CLOCK.

really? wow - oh my gawd... (snicker).

> With due and kind respect, have you been reading my messages?

yawn... :-) yep. Read them all. I love your retorts...

> accuracy.

etc.

> For my part these are not an integral component in the

So then the issue is moot.