[LEAPSECS] Leap second smearing test results

[Martin Burnicki]

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