[ntp:questions] NTP vs RADclock?

unruh unruh at invalid.ca
Thu Jun 7 06:19:31 UTC 2012


On 2012-06-07, skillzero at gmail.com <skillzero at gmail.com> wrote:
> On Jun 5, 6:46?pm, Julien Ridoux <jul... at synclab.org> wrote:
>> On Tuesday, June 5, 2012 9:12:42 AM UTC+10, E-Mail Sent to this address will be added to the BlackLists wrote:
>
> Thanks for response. It would be great to have a simplified
> description of the algorithm. I've read most of the docs on the
> synclab site. I'm trying to synchronize several devices to a reference
> clock of a similar device rather than to a true wall clock time of a
> real NTP server. I can't use the RADclock code directly because it's
> GPL so I'd like distill the algorithm down to something I can
> implement from scratch. I'd like to adapt my current NTP client and
> server code to use RADclock so I can compare performance. I'm aiming

Why not just use the reference implimentation of radclock for the tests?


> for 10 microseconds or less of sync on a wireless LAN with a fast

Not going to work. 

> initial sync time (less than 5 seconds, but I can send many packets

In 5 sec you could set the time, but you cannot get a good estimate of
the rate. 

> close together if needed). I haven't been able to get even close to
> this with my current NTP code (Ethernet is close, but WiFi introduces
> a lot of variability). Some of the key points seem to be:

Precisely. And Radclock will not help with that. It uses the same ( or
perhaps much slower) synchronization algorithm.

>
> 1. Feed forward: Use raw TSC instead of the time value adjusted by the
> algorithm. Is there more to this? Should raw TSC values be used for
> offset sync calculations or should the raw TSC be scaled by the latest
> adjusted rate (which would seem to be partially feed-back vs fully
> feed forward)?

The "time" of the remote clock is measured with the TSC/HPET/.... raw
clock. The packets exchanged are filtered to get the best ones (takes
time) and the rate and offset of the TSC calculated. If you want a
difference clock, only the rate is used. to make the transfer from TSC
differences to time differences. 


>
> 2. Separate offset sync from rate sync. What I wasn't sure about is
> why the rate sync would be so much more stable than offset sync since
> they seem to both come from the same packet exchanges. Is the
> advantage that the rate sync is smoothed over time whereas the offset
> sync isn't?

If you correct the clock for offset, the only way you can do that is to
somehow shift the time. Thus if you want the difference in times from t0
to t2 when you corrected the offset at t1, that offset correction will
affect the time difference between t2 and t0. Thus, if you only correct
determine the rate, the difference in raw times times the rate will
directly give you the time difference. 


>
> 3. Use only the lowest RTT samples. NTP also does this so I wasn't
> sure where the advantage was here.

Their algorithm seems, in the hints in the paper, to be more
sophisticates/complex than the simple "best of 8" algorithm of NTP. 

>
> 4. Weight samples by their RTT. There's some mention of this in the
> documents, but I wasn't sure what the algorithm was for determining
> the weights or adapting them as conditions change (e.g. if network
> load increased for a long period of time, which would also cause RTT's
> to increase due to queuing in routers, etc.).

Then those samples would be thrown out, and the clock allowed to
freewheel until the samples settled down again. 

>
> Are there other key aspects of the algorithm that I'm missing?

I do not know it, the above are my conclusions from reading the docs I
have read. They could be all wrong. 



More information about the questions mailing list