[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 ;-)
> Dale
> David L. Mills wrote:
>> 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