Actually, that's not completely correct. While the NTP standard doesn't have any definition of two-step, the reference implementation ntpd includes support for two-step operation in some modes. It is called interleaved mode. It still doesn't change any of your points but it is there.
From: [email protected] [mailto:[email protected]] On Behalf Of Tal Mizrahi Sent: Monday, October 28, 2013 11:57 AM To: Kevin Stanton Cc: [email protected]; [email protected] Subject: Re: [ntpwg] [TICTOC] New version of draft-mizrahi-ntp-checksum-trailer Hi Kevin, Just to make sure we are on the same page: this thread started out as a thread about NTP, and specifically about the following draft: http://tools.ietf.org/html/draft-mizrahi-ntp-checksum-trailer-01 I think the point you suggested is basically a religious discussion of one-step vs. two-step clocks in PTP. The example I referred to in the thread below is a PTP slave as an analogous example to an NTP client. Since NTP is always one-step (no two-step mode in NTP), in our context the actual time-of-day has to be maintained in HW. Please let me know if this makes sense. Thanks, Tal. From: Kevin Stanton [mailto:[email protected]] Sent: Monday, October 28, 2013 7:52 PM To: Tal Mizrahi Cc: Harlan Stenn; [email protected]; [email protected] Subject: Re: [TICTOC] [ntpwg] New version of draft-mizrahi-ntp-checksum-trailer This is a somewhat unrelated question, but why not eliminate the servo? If a software entity is the consumer of PTP time, I wonder if the benefit of avoiding the y=mx+b computation (to compute PTP time from the time of the free-running LAN hardware counter) is worth the trouble of disciplining the hardware clock. In other words, the hardware engine maintains a time reference and software maintains the parameters for translating that time reference to PTP time (also for hardware-captured Rx and Tx timestamps). Of course, this doesn't apply to one-step master ports. Thoughts? Kevin Stanton. On Mon, Oct 28, 2013 at 1:38 AM, Tal Mizrahi <[email protected]<mailto:[email protected]>> wrote: Hi Harlan, >In the "Figure 1" case "core" packet timestamps come from the kernel and the >new packet timestamp will be added by the hardware engine. >I understand the following question is outside the scope of this document, but >how can one determine how well sync'd the internal clock is with the clock in >the accurate timestamp engine? Well, indeed it is strictly an implementation question. For example, in typical PTP implementations (that I am familiar with) the accurate clock is only maintained in one place, i.e., in the HW engine. The SW stack includes the servo algorithm; the SW stack regularly computes the necessary offset or frequency adjustments, and whenever necessary sends update commands to the HW engine about these adjustments. Thus, the SW stack does not need to maintain an additional clock, since all its computations are performed WRT the HW clock. Thanks, Tal. -----Original Message----- From: Harlan Stenn [mailto:[email protected]<mailto:[email protected]>] Sent: Monday, October 28, 2013 10:09 AM To: Tal Mizrahi Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [ntpwg] New version of draft-mizrahi-ntp-checksum-trailer Just some thoughts, and I hope I'm awake enough to type this... There seem to be several issues here. In the "Figure 1" case "core" packet timestamps come from the kernel and the new packet timestamp will be added by the hardware engine. I understand the following question is outside the scope of this document, but how can one determine how well sync'd the internal clock is with the clock in the accurate timestamp engine? If we have TX and RX hardware timestamping capabilities, we can use NTP's interleave mode to communicate these timestamps as well. Having said that, I'm sure there is something to be learned from implementing Tal's proposal. H _______________________________________________ TICTOC mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tictoc
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
