On 2012-06-07, skillz...@gmail.com <skillz...@gmail.com> wrote: > On Jun 5, 6:46?pm, Julien Ridoux <jul...@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. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
