There are a variety of different implementation techniques, some of which do use free-running counters on the hw side, mapped to a software function up higher. Some NIC vendors are already doing that. One of the challenges for that type of operation is that the entire system must be aware and designed for that purpose until kernels/drivers/applications catch up. The beauty of the "inline" function is that it can be inserted into the process, correcting errors on the input and/or output without changing the system at other layers.
The tight coupling of the servo to the timing hardware also tends to allow better precision in many cases, running in real-time or at high(er) data rates. For some of our designs, we are synchronizing slave clocks in the sub 100ns (or better) in the presence of very high traffic loads. Obviously, the application for this class of synchronization service is much more targeted than Internet (capital I) but the market does exist so why not use the technology. From: [email protected] [mailto:[email protected]] On Behalf Of Kevin Stanton Sent: Monday, October 28, 2013 10:52 AM To: Tal Mizrahi Cc: [email protected]; Harlan Stenn; [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
