[ntpwg] ntpwg Updated NTPv4 Protocol Specification/timestamp location

[Kurt Roeckx]

On Tue, Feb 19, 2008 at 09:14:19AM -0500, Brian Utterback wrote:
>
> > This gives:
> > offset = 1/2 * [(T2-T1) + (T3-T4)] = 1/2 * [(3-0)+(5-6)] = 1.
> >
> > 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.

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.

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

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