[ntp:questions] Re: status of multicast

Dale Schultz dDOTschultz at nospam-sympatico.ca
Wed Dec 1 02:18:18 UTC 2004


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