[ntp:questions] Re: status of multicast

David L. Mills mills at udel.edu
Tue Nov 30 00:32:47 UTC 2004


As I said in my last message, it doesn't work the way you think. The 
first broadcast message received fires up an association, but the time 
is not used directly. Instead, a unicast client/server volley measures 
the offset and delay following which the time is set and the offset of 
the previous broadcast message(s) computed. Further broadcasts are 
corrected by this offset before being used. The delay of course is 
meaningless, but doesn't hurt either.

This assumes the unicast trip is terrestrial. If the server response is 
via the satellite, things would work as above, but incur a significant 
offset error.

PBS is now using NTP multiplexed in its live program feed. I don't know 
if they allow the volley to take place or whether a terrestrial path is 
available. Complicating things is the fact NTP packets might fight with 
MPEG packets and incur significant jitter. I am told the multiplexing 
occurs right at the codec.


David Woolley wrote:

> In article <cofbpj$3li$1 at dewey.udel.edu>, David L. Mills <mills at udel.edu> wrote:
>>The initial clock offset is computed with unicast and should not involve 
>>a step adjustment, unless the initial system clock is off by over 128 
> There are two possible interpretations of the system described here.
> Let's assume that terrestial propagation delay is 40ms and satellite
> delay is 300ms.  In the more likely scenario, the unicast measurement
> will measure a round trip time delay of 340ms and estimate a propagation
> delay of 170ms, which will be 130ms too low, so the time will be wrong
> by more than the step limit, although things may not step unless there
> was another source of time that was actually correct.  In this, case,
> the time estimate from the unicast measurement will have the same error
> as from multicast measurements.
> The other interpretation, which better fits the wording of the enquiry,
> but would be unusual for such a system, is that the unicast is purely
> terrestial, in which case the estimated delay will be 40ms and the 
> time measurement accurate on the unicast measurement, but the multicast
> will be undercompensated, so will be slow by 260ms.  If the system were
> to make use of the unicast time estimate, it would get a conflicting
> estimate from the multicast and likely go into step error recovery.
> If it ignores the unicast offset, it will simply have a large static
> error, as in the first case.
> (Normal satellites assume a consumer type user that makes small requests,
> over a terrestial back channel, and receives large responses, over the
> satellite.)

More information about the questions mailing list