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

[David L. Mills]

Guys,

The 1588 provisions for switches and routers is called a boundary clock. 
It requires intricate management of various fixed latencies and queueing 
delays. 1588 NICs known to me use the Intel chipset which has an onboard 
ARM processor very definitely provisioned by firmware. As for modifying 
NTP to simulate the 1588 two-step protocol, a description on how to do 
this is in the architecture briefing on the NTP project page.

Dave

Heiko Gerstung wrote:

> Sasha,
> I am sorry but my reference to "special hardware" in the context of TC
> should have been "special firmware" and was based on the assumption that
> routers are hardware devices. It might be enough to modify ntpd to work
> in a "forwarding mode" on such a router - instead of the current BC-like
> operation (get sync from one side and sync others on the other side).
>
> Best Regards,
> Heiko
>
>
> Sasha Vainshtein schrieb:
>
>> Heiko,
>> Thank you for a prompt response.
>> However, the question was not so much about special HW as about the
>> need to modify the protocol to make the routers on the way to inspect
>> the PTP packets they normally should not look at beyond their IP headers.
>>
>> Regards,
>> Sasha
>>
>>
>> ------------------------------------------------------------------------
>> *From:* Heiko Gerstung [mailto:heiko.gerstung at meinberg.de]
>> *Sent:* Wed 24-Oct-07 02:57
>> *To:* Sasha Vainshtein
>> *Cc:* stbryant at cisco.com; mayer at ntp.isc.org; NTP Working Group; Brad
>> Knowles; Israel Sasson; Alon Shtern; Osnat Shasha
>> *Subject:* Re: [ntpwg] Documents, slides, etc. from WG meeting
>>
>>
>> Sasha Vainshtein schrieb:
>>
>>> Heiko, Stewart and all,
>>> I just wonder if the PTP "transparent clock" (TC) mechanism is not in
>>> contradiction with the way IP routers are supposed to work?
>>> When PTP runs over IP, at least some of the PTP traffic (DELAY_REQ and
>>> DELAY_RESP messages ) are unicast UDP/IP Packets running between the PTP
>>> Slave and PTP Master with the well-known UDP port assigned to PTP. Hence
>>> the "normal" routers would simply pass these packets thru without even
>>> looking at the UDP ports not to mention UDP payload (i.e.., PTP proper).
>>> Of course one may add the "router alert" option to these packets (even
>>> if, AFAIK, PTP does not specify that), but even this would hardly help
>>> since the router would probably simply put the packet on the "slow
>>> path".
>>
>> That is correct, a TC concept always would include special hardware which
>> supports this mode. Just like hardware timestamping would require
>> special NICs.
>>
>> Heiko
>>
>>
>>> My 2c
>>> Sasha
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: ntpwg-bounces+sasha=axerra.com at lists.ntp.org
>>> [mailto:ntpwg-bounces+sasha=axerra.com at lists.ntp.org] On Behalf Of Heiko
>>> Gerstung
>>> Sent: Wednesday, October 24, 2007 4:06 PM
>>> To: stbryant at cisco.com
>>> Cc: mayer at ntp.isc.org; NTP Working Group; Brad Knowles
>>> Subject: Re: [ntpwg] Documents, slides, etc. from WG meeting
>>>
>>> Stewart Bryant schrieb:
>>>
>>>> Heiko
>>>>
>>>>> 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).
>>>>>
>>>> There is nothing to stop NTP doing h/w timestamping per se. The
>>>> critical difference is that PTP (1588) does on path correction
>>>> through the use of the TC mechanism. If TC were added to NTP the two
>>>> protocols would provide the same level of accuracy.
>>>
>>> I agree. The TC concept introduces quite a number of security problems,
>>> which have been addressed in V2 but obviously lead to an increased
>>> complexity. Adding a few things like hw-timestamping and on path
>>> correction to NTP would result in a synchronization protocol which
>>> offers a very good performance over both a WAN link and a controlled LAN
>>> environment (plus compatibility to millions of existing clients). Well,
>>> I have to go and talk to my engineers now :-)
>>>
>>> Best Regards,
>>> Heiko
>>>
>>>
>>>
>>>> Stewart
>>>>
>>>
>>> --
>>> ------------------------------------------------------------------------
>>>
>>> *MEINBERG Funkuhren GmbH & Co. KG*
>>> Lange Wand 9
>>> D-31812 Bad Pyrmont, Germany
>>> Tel.: ++49 (0)5281 9309-25
>>> Fax: ++49 (0)5281 9309-30
>>> eMail: heiko.gerstung at meinberg.de <mailto:heiko.gerstung at meinberg.de>
>>> Internet: www.meinberg.de <http://www.meinberg.de/>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Meinberg radio clocks: 25 years of accurate time worldwide
>>>
>>> _______________________________________________
>>> ntpwg mailing list
>>> ntpwg at lists.ntp.org
>>> https://lists.ntp.org/mailman/listinfo/ntpwg
>>
>>
>> --
>> ------------------------------------------------------------------------
>>
>> *MEINBERG Funkuhren GmbH & Co. KG*
>> Lange Wand 9
>> D-31812 Bad Pyrmont, Germany
>> Tel.: ++49 (0)5281 9309-25
>> Fax: ++49 (0)5281 9309-30
>> eMail: heiko.gerstung at meinberg.de <mailto:heiko.gerstung at meinberg.de>
>> Internet: www.meinberg.de <http://www.meinberg.de/>
>>
>> ------------------------------------------------------------------------
>>
>> Meinberg radio clocks: 25 years of accurate time worldwide
>>
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg