[ntpwg] NTPv4 draft-8 to draft-9 changes / alternative paragraph

[David L. Mills]

Greg,

What does the Symmetricom grandmaster do on a 100BAS-TX networ? I assume 
the NIC chip strikes the timestamp on the JK symbol pair, right? Does it 
assume a preamble is present and adjust the timestamp to the SOF octet?

Stuart's comment about the trailer timestamp is very real. If the two 
ends of the path are at different rates and a switch/router is in 
between, one or the other ends cannot produce a trailer timestamp from a 
preamble timestamp, even if the rates and packet lengths are known. This 
is very clearly evident in the note we sent. The only way to fix this is 
using preamble timestamps at the transmitter and trailer timestamps at 
the receiver. You can argue the need to do this on the basis of the 
improvement in accuracy obtained, but it is an engineering reality.

Dave

Greg Dowd wrote:

> I still think the quasi-leading edge (SOF) is a good compromise. If you
> can only timestamp after you have received a complete packet, I wonder
> if you have the intended definition of access to the physical layer. If
> you do, common practice is to strike a timestamp on SOF and then make a
> decision to save once you've analyzed the frame. If you have physical
> layer access only at the end (but it's deterministic), it seems like you
> could make an empirical or predefined adjustment to approximate ingress
> time.
>
>
> Greg Dowd
> gdowd at symmetricom dot com (antispam format)
> Symmetricom, Inc.
> www.symmetricom.com
> "Everything should be made as simple as possible, but no simpler" Albert
> Einstein
>
> -----Original Message-----
> From: ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org
> [mailto:ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org] On Behalf Of
> STUART VENTERS
> Sent: Thursday, February 28, 2008 1:25 PM
> To: jack.burbank at jhuapl.edu
> Cc: ntpwg at lists.ntp.org
> Subject: [ntpwg] NTPv4 draft-8 to draft-9 changes / alternative
> paragraph
>
> Jack,
>
> It looks like the changes from NTPv4 draft-8 to draft-9 are editorial
> except for a couple of new paragraphs.
>
> The editorial changes mostly clean up how references are cited. (Nice
> job, it's much better.)
>
> The new paragraphs are as follows:
>
> On page 23 the following was added:
> If NTP has access to the physical layer, then the timestamps are
> associated with the beginning of the symbol after the start of frame.
> Otherwise, implementations should attempt to associate the timestamp
> to the earliest accessible point in the frame.
>
>
> On page 25, the following was added:
> The Receive Timestamp and the Transmit Timestamp (set by the server)
> are undefined when in a KoD packet and MUST NOT be relied upon to
> have valid values and MUST be discarded.
>
>
> As an implementer, I'm ok with everything except the new page 23
> paragraph.
>
>
> I'm working on transporting time to the edge of an access network for
> one-way packet delay measurements. The server is back in the cloud with
> 1G interfaces. The client is at the end of a T1 link. The goals are
> modest, to make 1mS accurate measurements. After adding up all the
> tolerances, in order to get enough accuracy, I'm going to have to
> violate the page 23 paragraph.
>
>
> Here's an alternative paragraph which documents current practice, works
> on existing packet paths, and leaves wiggle room for future spec efforts
> with more time for careful study.
>
>
> For interoperatability with existing equipment (switches, routers, and
> the reference NTP implementation), implementations should use the
> following guidelines for associating timestamps with physical layer
> transitions. Receive timestamps should be at the first point which
> indicates a complete, good frame has gone by. Transmit timestamps
> should be at the first point which indicates that a frame transmission
> has started. Accuracy requirements and media specific details are FFS.
>
>
> Regards,
>
> Stuart Venters
>
>
>
>
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg