[ntp:questions] Re: status of multicast
David L. Mills
mills at udel.edu
Tue Nov 30 00:32:47 UTC 2004
David,
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.
Dave
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