[ntpwg] Documents, slides, etc. from WG meeting
GDowd at symmetricom.com
Wed Oct 24 20:45:29 UTC 2007
At the recent ISPCS2007 plugfest, there were dozens of oem's demoing v2
of IEEE1588. Symmetricom demonstrated v2 default profile (multicast)
and telecom profile (unicast) as did many others. The v2 draft isn't
final yet which I imagine is why you don't see "pre-n" grandmasters
showing up as GA product.
In the unicast, multicast arena the same problem with delay requests
already applies but it's even worse. V1 delay requests/response are
multicast (many-to-many). In the v2 unicast model, each client
negotiates their own announce, sync and delay request flows with the
master. More load on the master but the other ne's get the benefit.
Also, depending on the physical network implementation, some networks
don't allow multicast in both directions.
There is discussion ongoing on blended approaches such as that you
mentioned (mc sync with unicast delay) but that has the stronger
possibility of creating path asymmetry for time applications. One thing
I haven't seen mentioned is separation of sync and servo. In ntp, the
servo is intrinsically part of the protocol while 1588 separates the
Lastly, regardless of the protocol the network itself is only capable of
passing phase and frequency to some level which is very difficult to
identify. Google minTDEV.
Ok, jury duty calls.
From: ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org
[mailto:ntpwg-bounces+gdowd=symmetricom.com at lists.ntp.org] On Behalf Of
David L. Mills
Sent: Wednesday, October 24, 2007 11:12 AM
Cc: NTP Working Group; tictoc at ietf.org
Subject: Re: [ntpwg] Documents, slides, etc. from WG meeting
I have carefully trod over the V2 spec and investigated the available
1588-capable devices. You have to be very careful when comparing NTP and
1588. The bottom line is that NTP is best used to synchronizes computer
system clocks, while 1588 is best used to synchronize hardware interface
clocks and other data acquisition or telecom devices on a LAN. To
sustain the best accuracy, special Ethernet switches called boundary
clocks are necessary, so 1588 would not normally be expected to transit
a level-3 router, although in priciple it could.
The comments about 1588 V1 and V2 are interesting. All the devices I
know about from Symmetricom, Meinberg and 1588 Ethernet interfaces are
V1 (1588-2002). The Intel chipsets should be able to do both. The
Symmetricom 1588 grandmaster costs several thousand bucks and doesn't
even do NTP. The Meinberg grandmaster does 1588 and NTP and in fact does
everything the public NTPv4 distribution does, including Autokey.
There are a few straightforward issues that might have been overlooked.
The computer system clock is typically interpolated by the PCC/TSC with
resolution 1 ns, but reading it via syscall typically burns 500 ns in
modern silicon. The resolution of a 1588 timestamp is 1 ns, while the
resolution of an NTP timestamp is 0.232 ns, although the difference is
not significant. It is reasonable that the ioctl time to fetch a
timestamp from a 1588 interface would be comparable to the time to read
the system clock, 500 ns.
The TCXO rock in a 1588 interface is not likely to operate at
frequencies much above 20 MHz, although a cold rock might be higher. In
other words, the 1588 resolution as a practical matter will be in the 50
ns range. The NSI Etherface and Symmetricom grandmaster claim resolution
of 50 ns.
What the above suggests is that 1588 will likely find the most important
application to synchronize LAN hardware interface clocks to a
grandmaster to the order of 50 ns. Real-time devices can provide signals
that latch the interface clock which is later read by the program. This
has nothing to do with the computer system clock.
However, it is interesting to speculate on how 1588 and NTP could
interoperate or support each other. In one approach 1588 can be used
within a LAN with time exported beyond the level-3 router by NTP. In
another, 1588 interfaces can be used to derive precision timestamps for
use by NTP. A project on my shelf is to modify the driver for my 1588
Etherface for use as a reference clock driver.
In answer to a previous question, 1588 V2 has the same limitations as
NTP; both use four timestamps to compute offset and delay and assume the
one-way delays are very nearly the same. There is a proposal for
security extensions to 1588, although it does not address the issue of
possibly degraded accuracy. Since 1588 uses hardware derived timestamps
and is not expected to face seriously hostile attacks as assumed in NTP,
this might not matter. As a very simple security provision, 1588 could
well adopt the NTP protocol defenses used to deflect hostile replays and
lost packets. This does not change the protocol or packet format.
Finally, the observation that 1588 multicast might become deprecated is
interesting. I make no judgement about that, but Symmetricom promotes
its use in networks with thousands (!) of 1588 slaves. Well, maybe; the
SYNC message is one-to-many, but this will be followed by thousands of
DELAY_REQ messages imploding at the grandmaster.
Brad Knowles wrote:
> On 10/24/07, Stewart Bryant wrote:
>> In discussing 1588, you need to make sure you are talking about the
>> V2 spec. V1 is not likely to see significant deployment, whist V2 is
>> likely to get significant hardware support and hence be widely
> Therein lies the problem. I've been going through the page at
> <http://ieee1588.nist.gov/>, and I can't find any real discussion of
> the protocol, or specifics of the implementations. I didn't even find
> any reference to V1 versus V2, and hence did not know that there was
> an updated version.
> Sure, they reference specific chipsets as implementing IEEE 1588, and
> other specific devices (this is how I found out about the clock that
> Meinberg makes).
> But when the description given for IEEE 1588 is completely circular in
> nature, just exactly what good does that do for anyone?
>> Both V1 and V2 can use multicast IP encapsulation and you can in
>> principle build an IP multicast net, but I have always regarded this
>> mode of operation as a little strange and unlikely to ge deployed
>> outside a highly controlled network. I doubt if we will ever see the
>> 1588 multicast mode on the Internet.
> We've talked to one of the guys at ISC about broad use of multicast on
> the Internet, and they've explained why they believe that would be a
> bad idea.
> You may get multicast internal to a given network at a single entity,
> but you're unlikely to get it anywhere else.
>> However V2 can run over a unicast IP connection, and this is likely
>> to find use in wide area networks. Indeed it exists largely to
>> support the needs of the telecommunications operators for a method of
>> providing clock sync over packet.
> If it's used by telecom operators, why do they need IP or anything
> else that heavy? I mean, if we're talking about something like SONET
> synchronization, and they're worried about sub-nanosecond resolution,
> then it seems to me that IP is a very hefty hammer to be wielding.
>> I am not sure what you mean by this. How the grand master acquires
>> and locks to an external clock reference is outside the scope of the
>> protocol, but it's also outside the scope of the NTP.
> But we have reference clocks, right? And we have a defined way to
> interface with them?
> Honestly, I'm not trying to argue. I'm trying to understand better
> where IEEE 1588 fits into the picture, and I'm just not finding much
> in the way of what I consider to be useful documentation on the IEEE
> From what little I can tell, it seems to me that IEEE 1588 is much
> more oriented towards a closed single-entity local area (or
> near-local area) network environment, where you don't care if you're
> sync'ed to any given external reference, or how close or far you may
> be from The One True Time, you just care that all your internal
> slaves are sync'ed to your given master, and that you have some
> pretty tight tolerances on how far out of sync the slaves can get.
> In contrast, it seems to me that NTP works well on the broader WAN
> multi-entity internet (global and beyond), and that it can work just
> fine on smaller scale single-entity networks where sub-nanosecond
> accuracy timekeeping is not required.
> The two protocols seem to complement each other pretty well, and it
> would appear that the folks at Meinberg agree.
> Ahh, okay. Found the URL for one of the tutorials at
> <http://ieee1588.nist.gov/tutorial-basic.pdf>, which was a little
> more diffcult to find than it needed to be, thanks to the frame-based
> way the web pages are laid out.
> Anyway, Page 6 of the PDF is where we want to start, where they
> specifically compare IEEE 1588 and NTP, among others. I think
> they're wrong to target the peer-to-peer mode exclusively for NTP,
> but that is certainly one potential model that could be used with
> NTP. There are other master/slave relationships that would be more
> typical for use with NTP, but that doesn't really affect the
> conclusions you can draw from those slides.
> Slide 9 is also useful:
> Objectives of IEEE 1588
> + Sub-microsecond synchronization of real-time clocks in
> components of a networked distributed measurement and
> control system 
> + Intended for relatively localized systems typical of
> industrial automation and test and measurement environments. 
> + Applicable to local area networks supporting multicast
> communications (including but not limited to Ethernet)
>  indicates objectives that may be extended in version 2
> Hmm. Did they fix the assumption of symmetric delays between master
> & slave in V2?
> Or the complete lack of any kind of security? I mean, UDP is
> trivially easy to spoof, and given that everyone on the subnet is
> supposed to be operating with the exact same information and the
> exact same algorithms, it seems like it would be simple to see who
> the current master clock is and spoof them as being bogus and force a
> new master clock to be selected -- which you should be able to
> guarantee is your selected trojan machine....
ntpwg mailing list
ntpwg at lists.ntp.org
More information about the ntpwg