Dave, A while back in an email thread you pointed out that our ID (draft-marlow-tictoc-computer-clock-accuracy-00.txt) only addressed interleaved broadcast and did not include interleaved symmetric mode and that a lot of the detail information is in your book. We bought the book and have learned a lot particularly in section 16.6 where you have measurement data for interleave mode operation. Your Backroom LAN example is similar to the experiments we ran. We had some questions:
1) In your Backroom LAN example the GPS clock server ran in client/server mode with clients Macabre and Mort. Would you expect better accuracy if client/server mode is used (as you did) versus if interleave broadcast mode were used between this server and these two clients? 2)Similar in your Campus LAN example you used client/server mode in some of the operations versus using interleave broadcast, where is client/server mode better than interleave broadcast to use? 3) In your Backroom LAN example, Macabre and Mort ran interleaved symmetric mode between each other. Would not the dominant synchronization factor come from the GPS clock server, given its lower stratum number? Is the interleaved symmetric mode exchanges providing a secondary effect to keep these two together? Dave -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Karen O'Donoghue Sent: Wednesday, June 08, 2011 23:10 To: NTP Working Group; [email protected] Subject: [TICTOC] Fwd: Re: [ntpwg] Fwd: reminder for remote participation in today's tictoc meeting Folks, This came to me personally, and I neglected to send it on to the ntp and tictoc wg lists. My apologies for the delay. The question before us is whether or not the interleave capability should be properly documented and where the resources will come from to complete the effort. Karen -------- Original Message -------- Subject: Re: [ntpwg] Fwd: [TICTOC] reminder for remote participation in today's tictoc meeting Date: Tue, 12 Apr 2011 18:18:43 +0000 From: David L. Mills <[email protected]> <mailto:[email protected]> To: [email protected] Karen, The following is in response to the ID you distributed. I offer it as a candidate for distribution to th eWG members. Dave This internet draft describes experiments using the interleaved broadcast mode recently incorporated in the NTP reference implementation. The experiments do not include the interleaved symmetric mode, which provides similar functionality in peer-to-peer configurations. For reference, these modes, their relevance to PTP and related information are discussed in detail in Chapters 15 through 17 of the book "Network Time Synchronization - the Network Time Protocol on Earth and in Space, Second Edition, CRC Press 2011, as cited on my web page www.eedis.udel.edu/~mills <http://www.eedis.udel.edu/%7Emills> . However, most of the information relevant to the followings discussion can be found in the white papers at www.eecis.udel.edu/~mills/ntp.html <http://www.eecis.udel.edu/%7Emills/ntp.html> . Of particular interest are the documents "Analysis and Simulation of the NTP On-Wire Protocol" and "Security Analysis of the NTP Protocol." Both of these documents represent an update since t he book was published late last year. Readers may wonder why these documents have not been published as an update to the protocol specification RFC-5905, which would have been the expectation several years ago in the adolescent Internet. However, the effort necessary to publish an ID with figures, tables and equations is nowadays simply unacceptable. My experience with RFC-5905 and RFC-5906 over the last five years of publishing effort is not sustainable. Thus, unless some collaboration, perhaps the TICTOC working group, chose to publish them as IDs, I will not commit that adventure myself. First some nomenclature that may help in the following discussion. Timestamps captured for the clock discipline are classed as hardstamps, drivestamps and softstamps. Softstamps are captured during the course of user-space processing; they may be corrupted by operating system and device latencies, as well as transmission delays. Drivestamps are captured during the packet interrupt routines, so are much less affected by operating system scheduling and competition with other programs. Hardstamps are captured by dedicated hardware means, typically in the PHY layer of the network interface card (NIC). While the details vary, the typical intercept point is the media independent interface (MII), which monitors the frame level interface on a character by character basis. The capture means is usuallt a field-programmable gate array (FPGA) that parses the packeet, inserts timestamp data and recomputes the UDP checksum. The interleaved capability was originally not intended for NTP, but for the Proximity-1 protocol specified by the Consultive Committee on Space Data systems (CCSDS). The Proximity-1 protocol is designed for communication between spacecraft in the vicinity of Mars and for future missions in the vicinity of the Moon. Space data links are often operated at very low data rates compared to typical Ethernet links. Typical rates range from 1 kb/s to 256 kb/s with very different data rates in each direction. Due to various queuing and transmission operations, the output delay can reach 30 s, so it is imparities that timestamps be captured close to the PHY layer. In the Proximity-1 desing, hardstamps are captured upon the passage of the ASM code combination at the beginning of each transmitted frame.. Queuing and transmission delays are not the only contributors to space data link delay. Reed-Solomon and convolutional encoding delays can be a large contribution to the link delay; however, these delays are a constant contribution to the lightwave transmission delay. These contributions - up to many seconds - can dwarf the lightwave transmission delays. In the NTP interleaved design, drivestamps are captured in the device interrupt routine - on input immediately after the frame has been received and before copying to an input buffer; on output shortly after the frame has been transmitted and before the buffer is released for the following input or output frame. This can become rather awkward in the case of NICs of the PCNET architecture, as data are copied directly from user space to device buffers directed by DMA descriptors. Drivestamps have been used on input for many years, but for output this is possible only using the interleaved modes. The result avoids the latencies due to the message digest computation, Autokey protocol data units, output queuing and frame transmissions, typically some 10-40 microseconds. It should be obvious from the documents that a primary motivation for the NTP interleaved design was protection from network errors and intruder attack. The detailed analysis and simulation are designed to demonstrate resistance to common corruptions such as dropped or duplicate packets and possible bogus attacks. The NTP design includes a four-level security model, the lower two levels might be considered for a PTP application. This is one of the most important difference between the PTP and NTP protocol designs; however, the NTP design might be considered overkill in a sheltered, isolated Ethernet network. Careful observers may notice an interesting anomaly with the interleaved broadcast mode. The preliminary volley intended to measure the roundtrip time uses basic mode, not interleaved mode. The reason for this requires some explanation. In times of old, the dominant concern was the 6-bone, an international consortium of multicast application developers. In that context with historic multicast configurations, including DVMRP and PIM, the multicast spanning tree was far different than the unicast spanning tree. Therefore, the preliminary volley was important to estimate the offset of the multicast server to the multicast client and thus the apparent one-way delay. In principle, with adroit protocolmanship, it would be possible to change the protocol to measure the interleaved roundtrip delay, which would be more appropriate for modern high-speed Ethernet networks. Karen O'Donoghue wrote: -------- Original Message -------- Subject: [TICTOC] reminder for remote participation in today's tictoc meeting Date: Thu, 31 Mar 2011 09:56:35 +0200 From: Karen O'Donoghue <[email protected]> <mailto:[email protected]> Reply-To: [email protected] Organization: ISOC To: [email protected], NTP Working Group <[email protected]> <mailto:[email protected]> Folks, This is a reminder that the tictoc working group will meet today from 17:40 - 19:40 CEST (15:40 - 17:40 UTC). The tools agenda for the IETF meeting (http://tools.ietf.org/agenda/80/) has links for the drafts, presentations, jabber chat room, and audio streaming to facilitate remote participation. Regards, Karen _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc ________________________________ _______________________________________________ ntpwg mailing list [email protected] http://lists.ntp.org/listinfo/ntpwg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
