[ntpwg] Documents, slides, etc. from WG meeting

Heiko Gerstung heiko.gerstung at meinberg.de
Wed Oct 24 12:07:27 UTC 2007


Brad Knowles schrieb:
> On 10/23/07, Danny Mayer wrote:
>
>   
>>>  A long discussion at end of meeting discussing the future of
>>>  timekeeping here in the IETF.  Is the future 1588 over IP?
>>>  NTP over IP?  No consensus was reached.
>>>       
>>  Could some explain exactly what that means? Is this a question of
>>  certain protocols (DNS and Kerberos come immediately to mind) that
>>  require that two interacting servers keep their clocks within X minutes
>>  of each other in order for various security requirements to work
>>  correctly or ro be assumed to be valid? Is it something else?
>>     
>
> Well, NTP is inherently an IP protocol.  From reading the IEEE 1588 
> page, it's not clear whether this works over IP or not, although it 
> does seem to work over Ethernet (and maybe others?).  But IEEE 1588 
> seems to focus on ultra-high resolution, like sub-microsecond or even 
> sub-nanosecond.  Meinberg appears to have a clock that does both NTP 
> and IEEE 1588.
>
> But I'm not seeing how IEEE 1588 can provide synchronization to an 
> outside reference, and I'm not seeing how it can be used outside of 
> certain limited circumstances on a pretty much pure Ethernet network.
>
>   

There are several mappings for IEEE1588 in V2, I guess that the UDPv4, 
UDPv6 (layer 3) and Ethernet (layer 2) based mappings will see a larger 
installation base in the future. As far as I remember, V2 is still being 
worked on in the standardization process, although it looks like it is 
almost done. That might be the reason why the IEEE1588 page does not say 
anything about it.

The main purpose of PTP/IEEE1588 is not "absolute" synchronization to 
UTC but "relative" synchronization to the same source. Since one of its 
design goals (as far as I interprete it) is sub-microsecond accuracy, it 
is not working very well over WAN links and other asymmetric network 
infrastructures (imagine the unpredictable delay a regular 
store-and-forward switch introduces when it is queueing packets) . NTP 
does a much better job in such an environment, no doubt about that.

 From our perspective (as a vendor selling products in both worlds) we 
see that PTP is trying to solve a lot of problems that NTP takes care of 
since a couple of years, like redundancy of sync references, unicast 
operation and security. The one thing that really enables PTP to reach 
an impressive accuracy level over an Ethernet/UDP connection is the fact 
that it uses hardware time stamping and therefore requires specialized 
hardware (if you want to benefit from that superior level of accurcacy).

Our GPS synchronized grandmaster is in fact a stratum 1 NTP timeserver 
with an add-on module which adds a PTP/IEEE1588 network port (with 
hardware timestamping) to the package. Of course there are other 
products (GPS synchronized grandmaster clocks) from other vendors. This 
type of product results in a PTP network being synchronized to an 
outside source (GPS), just like a GPS synchronized NTP server does the 
same for its clients.

Cheers,
Heiko



More information about the ntpwg mailing list