Eric, There are actually two burst modes IBURST when the server is unreachable and BURST when it is. They are independent of each other and both can be used at the same time. Currently, IBURST uses 6 packets, as that is a couple more than to pass the distance threshold and synchronize the clock. This actually is recommended; the following packets whether burst or not are delayed so that the average headway does not exceed the specified threshold, by default 16 s. The BURST mode also obeys the headway restrictions, but is intended to de-jitter in the cases I mentioned.
What set off my bell in response to your remark was an interesting observation when watching the clock filter operate. Start the daemon with a -d flag and watch the clock_filter and local_clock traces. Notice that there are often several samples discarded as not younger than the last used sample. This is a normal situation; however, it reveals that the probability of using another sample just after usin one is relatively low. In other words, when you find a sample you might as well give up and wait for the next burst. This needs to be confirmed. Dave Eric wrote: > On Mon, 28 Jan 2008 22:09:11 +0000, "David L. Mills" <[EMAIL PROTECTED]> wrote > for the entire planet to see: > <snip> > >>However, you give me an idea. Why not shut down the burst when the clock >>filter delivers the first sample? Gotta think about that. >> >>Dave > > > Hi Dave - > > I'm pleased to know I've provoked some new thoughts. If I understand your > post, burst mode was intended to get enough (lousy) samples into and > through the clock filters to allow for initial sync. Once the pipeline is > loaded no more "extra" polls are needed. > > But the rest of this sub-thread was about poll intervals that get so large > that the intervening equipment forgets about the flow and always, from then > on, gives lousy performance on the one and only poll in that interval. > > I guess we could kill two birds with one stone and shut down burst as you > suggest, until the interval gets longer, when it could make a reappearance, > perhaps as only a pair of packets. > > - Eric > _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
