[ntp:questions] Re: status of multicast
David L. Mills
mills at udel.edu
Wed Dec 1 04:24:33 UTC 2004
Don't fret; my recent work for NASA/JPL was for the Mars Internet, in
which 1500 ms is but a paltry tick. I used the simulator which is
included in the public NTP code. You might try that as a proof of concept.
Dale Schultz wrote:
> Thanks for the insight. I'm off to build a new network and maybe while
> doing it I'll have the opportunity to do some more experimenting. The
> typical round trip satellite delay I've seen is from 400 to 800 msec
> using terrestrial return. Now some of this might be delay introduced by
> the DVB IP encapsulator. I'll have to make sure section packing is off
> so there is no undue delay added to fill a DVB frame. In my previous
> tests I was using symmetric key authentication. I also used (at that
> time) the latest stable tarball. In this new network I'm building the
> return path is also going to be satellite. The typical round-trip
> satellite delay of this new network is 1500msec. So I think I may have
> a challenge ahead of me. When I get to that point it would be nice to
> have someone to bounce some ideas off of. So please don't run away ;-)
> David L. Mills wrote:
>> 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
>>> over a terrestial back channel, and receives large responses, over the
More information about the questions