David ,
The primary purpose of the scenarios illustrated in the book was to
quantify the output delay and the antisymmetric Ethernet card delays,
especially with Solaris. The GPS servers used for primary
synchronization operate only in client/server mode and so far as I know,
not in any interleave mode.
There has been recent interest in stateful servers, such as might be
supported using the MRU list now used for rate management. If this works
out, it might be possible to support an interleaved client/server mode.
This might be a topic for further research.
Dave
Marlow, David T CIV NSWCDD, W64 wrote:
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
th!
!
e 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
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
