Subject: Re: Clock synchronization with ISDN
To: Christian Kuhtz <chk@gnu.ai.mit.edu>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 02/17/1997 19:13:41
>What do you mean by "slow"?  Low bandwidth or high latency?  Would you care  
>to explain that in a little bit more detail?

>> If it's slow, then how much jitter is
>> that, and (at best) discretisation at the 9600-baud D channel line speed
>> adding?  Not  to mention  switching delays inside the telecom net?

>Most of the timestamps present in ISDN are generated by the last switch  
>before your end of the BRI or PRI, therefore latency will be reasonably low  
>(not more than your ISDN link itself (round-trip times of no more than 2-3ms  
>worst case).

Christian,

The issue here is  what the phase error between obtaining a
timing pulse (e.g., from DFC77, but for the sake of argument, let's
take it as a "perfect" time source) and delivering it to the ISDN
receiver.

You claim it's 2-3 ms "worst case" and manage to imply that's
low latency and low jitter. 

First, I find the claim hard to credit.  I beleive the *forwarding*
latency will be that low, but not when taking signalling-protocol
processing into account. Are you sure we're all talking about the same
thing? It's really 2-3 ms from the switch sampling its time source,
to the destination receiving the frame?  Do the fascicles really
require that for ISDN timestamps?

Second, even if it were true, you seem to think that constitutes
``good'' latency. In the context of NTP-synchronized clocks, a phase
error of 2-3 ms is execrable.  One wants three orders of magnitude
better.
That's not even mentioning the timestamps that aren't generated
locally.