Zefram wrote: > Martin Burnicki wrote: >> I've run some more tests with smearing of leap seconds, > > These new ones, with variable polling interval on the client, are much > more useful than the former ones with fixed polling interval. It seems > to me that these measurements should concentrate on clients with default > settings, because if one is able to configure the client to better follow > the smear then one could easily do an even better job by configuring > the client to follow an honest server and to introduce the smear itself.
Yes, that's basically what UTC-SLS does, and what has been discussed here for modifications in the kernel. However, this requires fiddling with *each* individual client right now, where no out-of-the-box solution is available for the client side. > Only the case where the client can't be specially configured is really > relevant to the concept of introducing the smear upstream. That's the intention. It's just a workaround for now. > I'd like to see a run of this client type with the 24 hour smears > that you used earlier, or of a fixed-polling-interval client with the > new 10 hour smears, so that variable polling interval can be directly > compared against fixed polling interval. I'd interpreted your earlier > tests generally based on the poll=10 client, in the expectation that > the default variable polling interval would behave similarly, but it's > not clear whether the reductions of polling interval that you see would > result in a significant difference in performance. > > It is strange that the polling interval varies so much more with the > linear smear than with the sinusoidal smear. I would have expected them > to remain stable at poll=10 for the bulk of the smear, after they've > recovered from the initial frequency change. There is a point 2.5 > hours into the smear where all the clients have returned to poll=10; > can you explain why they reduce it again after that? Unfortunately not. More tests to be done. Especially the cases where the server sends "poll 4" to its clients during the smear interval. On the one hand this seems to have an affect on the client, in that the client's poll interval decreases more than without it. On the other hand, why does the client poll only decrease to 6, even though the server suggests 4, and why is the client increasing its poll interval when the frequency seems to become "stable", even though the server still keeps suggesting "poll 4"? > Also strange that the three clients had such different reactions to the > end of the linear smear, having been so similar in their reactions to > the start of it, and similar in all parts of the sinusoidal smear. I think a problem with the linear smear is that the frequency does *not* change during smear interval, so the clients assume everything is fine again and ramp up their poll interval more or less. Then suddenly smearing stops, the frequency suddenly changes to its original value, and it depends on the time until the next poll how the client reacts. If the client has a long poll interval and/or polls only lately next time after smearing has stopped the time offset due to the changed frequency has increased much more than with a client that polls next time shortly after smearing has stopped. > It is interesting that when the server suggests a smaller poll interval > the shape of the smear makes a big difference to the tracking accuracy. > This is much like the difference that we intuitively expected the shape > to make in the first place. Not quite. The test with the fixed polling intervals have shown that the shape matters less if the smear interval is sufficiently large compared to the poll interval. Martin _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs