[ntpwg] [TICTOC] Re: Documents, slides, etc. from WG meeting

David L. Mills mills at udel.edu
Fri Oct 26 13:13:38 UTC 2007


Mark,

I think we have talked before. I was told that the Symmetricom 1588 
grandmaster does not do NTP, but I was not told it could do NTP as an 
option. at the same time. I was told the customer would have to buy a 
separate server for that. The Meingerg grandmaster I have does both 
without special order option.

The delay request/response behavior is as expected and does mitigate the 
implosion hazard. However, the features noted on the web page for the 
XLI suggest the device is safe for up to thousands of clients. My 
experience and that of USNO and NIST suggest loads like this present 
special hazards independent of 1588 or NTP.

Dave

Mark Elliot wrote:

> Since I'm intimately familiar with Symmetricom's NTP and IEEE 1588, I'd
> like to correct some observations. First of all, Symmetricom does offer
> an IEEE 1588 grandmaster. The same unit offers NTP at the same time.
> NTP is an option and it is on a second port from IEEE 1588 card. There
> is nothing to prevent anyone from placing both of these services on the
> same Internet subnet. It's true that the current IEEE 1588 grandmaster
> does support IEEE 1588 version 1. In the same platform we've also
> demonstrated IEEE 1588 version 2 in the last IEEE 1588 plug fest.
> Therefore, you can conclude that at some time in the future will be
> offering version 2 as well.
>
> On the subject of supporting thousands of IEEE 1588 clients this is
> true. For IEEE 1588 version 1, set at a two second sync rate, a delay
> request comes in from a client approximately every 30 seconds. This
> number is approximate for two reasons. Reason number one is I don't
> have manual in front of me right now and I'm going on remembered
> laboratory experience. The second and most important reason is this
> rate is randomized so that all the requests do not come in at once. On
> average, 1000 clients will generate just over 33 packets per second.
>
> For the most part IEEE 1588 works well in the real world. The only
> disadvantage of this scheme is when one grandmasters fails over to
> another grandmaster, the 30 sec. delay request message rate can ring the
> system more than some people would like. This is a well document and
> explored subject within the IEEE 1588 group. Version 2 has ways of
> mitigating this last effect as well as a host of other features.
>
> I hope this clarifies things, Mark Elliot.
>
> -----Original Message-----
> From: David L. Mills [mailto:mills at udel.edu]
> Sent: Wednesday, October 24, 2007 11:12 AM
> Cc: NTP Working Group; tictoc at ietf.org
> Subject: [TICTOC] Re: [ntpwg] Documents, slides, etc. from WG meeting
>
> Guys,
>
> 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.
>
> Dave
>
> 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
>>
> deployed.
>
>>
>> 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
>> website.
>>
>> 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 [0]
>>
>> + Intended for relatively localized systems typical of
>> industrial automation and test and measurement environments. [0]
>>
>> + Applicable to local area networks supporting multicast
>> communications (including but not limited to Ethernet)
>>
>> [0] 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....
>>
>
>
> _______________________________________________
> TICTOC mailing list
> TICTOC at ietf.org
> https://www1.ietf.org/mailman/listinfo/tictoc




More information about the ntpwg mailing list