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

From: "STUART VENTERS" <[email-masked]>
Date: Thu, 7 Feb 2008 09:34:35 -0600

Dave,

>>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.

Yeeeesssss, finally, your words match the example.
I had given up all hope.
Now it appears there is a glimmer of light in the long tunnel.

A consequence of your words appears to be that
  the resulting offset eqn calculated at A is:
offset = {[(t2 + D) - t1] + [(t3 + D) - t4]} / 2

for the example, offset = D = -(packet time)

If you agree with this baby step, then let's pop the question stack for the example.

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

73's,

Stuart

ps,  My morse is rusty, I meant to say QRT for I had truly given up.

_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: "David L. Mills" <[email-masked]>
Date: Thu, 07 Feb 2008 17:34:08 +0000

Stuart,

No, compare your equation with mine. The view has to be from A, so the 
delay cancels.

...-.-

Dave

STUART VENTERS wrote:

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

---

From: Kurt Roeckx <[email-masked]>
Date: Fri, 15 Feb 2008 22:24:48 +0100

> No, compare your equation with mine. The view has to be from A, so the 

I'm still not convinced.  So I'll try to make an example.  Let's assume
that it takes 2 second for the packet to travel from A to B and the
other way around.  That is, if A sends a physical signal from low to
high, B will see that change 2 seconds later.  Let's also assume that it
takes A 1 second to transmit the packet.  Then let's assume that A's and
B's clock are in sync, and that A takes the timestamp at the start of
the packet, and B and the end.

We start with A sending a packet at time 0.0.  A takes the time
when the packets starts to be transmitted, so sets T1 to 0.0.

The packet will start to arrive at B at 2.0, and stop at
3.0.  B takes the timestamp at the end of the packet
and will set T2 to 3.0.

It takes B 1 second to process the packet.  It will start to transmit
the packet at 4.0.  But since it timestamps the packets after
it's completly send, it will set T3 1 second later to 5.0.  B will inform
A about T3 with an other packet it will send later.

The packet starts to arrive at A at 6.0, which is when A takes
the timestamp, getting us T4 = 6.0.  The packet completly arrives at
7.0, but that doesn't matter.

This gives:
offset = 1/2 * [(T2-T1) + (T3-T4)] = 1/2 * [(3-0)+(5-6)] = 1.

While we expected the result to be 0.

Note that for the delay we don't have the problem.
delay = (T4-T1) - (T3-T2) = (6-0) - (5-3) = 4.

Kurt

---

From: Danny Mayer <[email-masked]>
Date: Mon, 18 Feb 2008 23:45:22 -0500

> While we expected the result to be 0.

Why would you expect that? The offset should always be non-zero as you 
yourself have demonstrated that it's taken time for the packet to travel 
between A and B.

Danny

---

From: Al Morton <[email-masked]>
Date: Tue, 19 Feb 2008 08:13:36 -0500

At 11:45 PM 2/18/2008, Danny Mayer wrote:
>...

Kurt,

B set T2 at the end of the packet, so it includes serialization time.
B set T3 at the end of the packet, where it excludes serialization time.
(A sets T1 and T4 at the beginning of the packets).

Consistency among senders and receivers seems to be important here.

movin' on,
Al

---

From: Brian Utterback <[email-masked]>
Date: Tue, 19 Feb 2008 09:14:19 -0500

> Consistency among senders and receivers seems to be important here.

Which was exactly the point that he was trying to show. Consistency
is important, or at least relevant. The maximum error introduced is
1 frame time. But marking start of packet is much easier than end of
packet, which involves making predictions.

-- 
blu

There are two rules in life:
Rule 1- Don't tell people everything you know
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
_______________________________________________
ntpwg mailing list
[email-masked]
https://lists.ntp.org/mailman/listinfo/ntpwg

---

From: Kurt Roeckx <[email-masked]>
Date: Tue, 19 Feb 2008 23:05:47 +0100

> yourself have demonstrated that it's taken time for the packet to travel

I think that "time for the packet to travel" is an unfortunate
choise of words here, since I used the 2 seconds in my example
for that.  It's the frame time, the 1 second in my example,
that's causing the change in offset.

Anyway, the point is that the clocks were in synch but because
of implementation details in the 2 products we end up calculating
an offset that isn't there.

> packet, which involves making predictions.

It all depends on what exactly your hardware can do for you.  It's
probably easy with most hardware to let it generate an interrupt
when the packet has completly arrived, so at the end of the frame,
or some time after that.  You'll probaly need special hardware that
can capture the time at the start of the frame.

And I think in case of generating an interrupt when sending a packet
it's probably not always clear what the relation between that interrupt
and the frame is.

Kurt

---

From: "David L. Mills" <[email-masked]>
Date: Thu, 21 Feb 2008 04:31:16 +0000

Guys,

May I offer a summary, analysis and proposal about all that has gone 
down here? Stuart Venters and I cooked it up.

The following document discusses software, hardware and driver 
timestamping schemes. It analyzes the errors with each scheme and 
combinations of schemes. It makes a specific recommendation on 
interoperation between all three schemes to achieve accuracies 
approaching IEEE 1588.

http://www.eecis.udel.edu/~mills/timestamp.txt

Dave