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

[David L. Mills]

Martin,

Yes, I am familiar with the distinction between boundary clocks that do 
or do not involve a control loop. Of course, NTP has the same 
distiction; however, the NTP control loop has a carefully defined 
transfer function that minimized the whip effect of cascaded control 
loops. 1588 could do the same thing, but most would consider that 
outside the scope of the specification. A 1588 bis could present such a 
specification.

One thing that may have escaped mention is that 1588 synchronizes the 
NIC drivers in the network, not necessarily the computer system clock. 
This adds another control loop to the impulse response. The time purist 
might use NTP at the edges of a private network, then distribute the 
local offset of the NIC relative to the NTP time to all other hosts 
which would then run the same discipline (NTP or kernel) for the local 
system clock. So,all hosts with have the same control loop dynamics and 
very small wiggles with respec to each other.

That bit of protocol wizardry could be incorporated in 1588 bis.

Dave

Martin Burnicki wrote:

> Dave,
>
> David L. Mills wrote:
>
>> 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.
>
>
> The boundary clock is just _one_ possible way to eliminate the latency of
> intermediate nodes between the grandmaster and the final client.
>
> In the NTP world this is comparable to an NTP server running on a 
> company's
> firewall or router, which gets its time from the outside world and 
> serves it
> to the internal network.
>
> Since each boundary clock includes a control loop, a number of cascaded
> boundary clocks results in cascaded control loops, maybe with unknown
> characteristics, which may let the overall control loop between the final
> client and the grandmaster become instable.
>
> So another approach is the transparent clock, which just adds to every 
> packet
> how much the packet has been delayed when it has traversed an 
> intermediate
> node. So even if there are several intermediate nodes, there's only on 
> big
> control loop which includes the grandmaster and the final client, 
> which can
> possibly easier be made stable than a number of cascaded loops.
>
> For existing NTP installations the similar configuration is when clients
> behind a firewall directly send queries to a server in the outer 
> world, and
> the queries and replies just go through the firewall, though of course a
> firewall or router would not try to compensate any latency it adds to 
> the NTP
> packets.
>
> The advantages and disadvantages of boundary clocks and transparent 
> clocks for
> this purpose have been discussed on several PTP plug fests and meetings.
>
> Martin