IEEE 1588 (PTP) specifies how updates are delivered. Unlike NTP, PTP
does not specify what devices do with these updates. In both cases,
stability in the absence of updates is mostly a function of the
quality of the local oscillator and not so much dependent on the time
protocol.
Kevin Gross
On
The IEEE 1588 standards are quite abstract so you won't find these
implementation details there. You need to read NIC datasheets. Many of
these are only available under NDA.
On Wed, Oct 19, 2011 at 8:36 PM, Nico Williams wrote:
> On Wed, Oct 19, 2011 at 9:21 PM, Kevin Gross wrote:
>
It would be nice to have timestamps on every packet but, for whatever
reason, this is not how most existing 1588 hardware works. Current hardware
keys off specific protocol identifier fields in packets and takes a
timestamp on match. There's some small amount of hardware buffer dedicated
to holdin
gt; On 10/18/2011 12:42 PM, Kevin Gross wrote:
>>
>>> It does seem reasonable to consider modeling encryption and decryption
>>> in as part of network latency. As long as delays introduced are the same
>>> each direction, the sync protocols will naturally subtract
ution work
through an IPSec connection. I guess your point is that an "IPSec
connection" should be defined as an IPSec connection _under active attack_.
I'm afraid not qualified to assess these larger-picture security questions.
Kevin Gross
On Tue, Oct 18, 2011 at 12:16 PM, wrote:
on packets, clock quality will
suffer. In the extreme case, all useful clock communication is lost and
nothing works. I don't think this situation is any different for clock
traffic than it is for other traffic. Encryption cannot prevent denial of
service.
Kevin Gross
On Tue, Oct 18, 2
timestamps all
packets attaching a hardware-generated timestamp to each receive queue
entry. That's what seems to be required here. This type of hardware combined
with two-step sync announcements (apparently supported by both 1588 and NTP)
could make for a workable solution.
Kevin Gross
On Tue, O
It does seem reasonable to consider modeling encryption and decryption in as
part of network latency. As long as delays introduced are the same each
direction, the sync protocols will naturally subtract out this contribution.
Kevin Gross
On Fri, Oct 14, 2011 at 11:25 AM, Nico Williams wrote
unencrypted connection also using two step.
Kevin Gross
On Thu, Oct 13, 2011 at 8:43 AM, Danny Mayer wrote:
> On 9/18/2011 9:41 PM, Cui Yang wrote:
>
IEEE-1588 (PTP) also cannot benefit from this as it is basically a
> hardware-stamping protocol and now you are routing it through a
