[LEAPSECS] Leap second smearing test results

[Martin Burnicki]

Hal Murray wrote:
> 
>> 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", ... 
> 
> I don't think the client pays any attention to that field in the packet.

Hm, when Harlan made the proposal then he said the client did.

Also, I've run the tests twice and in both cases the clients reduced the
polling interval faster and to a lower value than without the server
sending "poll 4".

Haven't yet found time to look at the source code myself, though. But
basically  I think it's a good idea.

In fact, Harlan proposed to let the server send "poll 4" even some time
before smearing starts, so the client is already polling in short
intervals when smearing starts, and can react quickly.

However, implementing this would have required quite some more fiddling
with the timers, so for my tests I decided to do it the easy way,
sending "poll 4" as long as smearing is active, and see if it makes a
difference.

> It reduces its polling interval when things change faster/farther than 
> expected and increases it when things are working smoothly.  (Sorry for using 
> non-technical terms.)

The terms are OK. ;-)

I know this is the way it works it is supposed to work in normal
operation, and the tests without having the server send "poll 4" show
that the client reduces the polling interval when it detects that the
frequency changes.

But anyway, it looks like this happens faster if the server sends "poll 4".

>> 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. 
> 
> Right.  Google's smear is off by 13.9 ppm.  At 1000 seconds, that's 14 ms worst case.
> 
> But how early do you want to poll?  If the client asks right after the smearing stops, there won't be any accumulated offset so it won't see any error and won't do anything.

The server ntpd knows the time when smearing will start. At the first
glance, an elegant way to implement this would be to look at the "poll"
value in the request packet and start sending "poll 4" e.g. 2 poll
intervals in advance. E.g., if a request comes in with "poll 10" the
server would start sending "poll 4" if smearing starts after less than
2048 s from now, and if a request comes in with "poll 6" it will do this
if smearing starts less than 128 s in the future.

However, let's look at this example which assumes that the client really
decreases its poll interval if the server suggests to, though eventually
not down to the level the server suggests:

1.) Request comes in with "poll 10" 2048 s before smearing starts.
Server replies with "poll 4".

2.) Client reduces its poll interval to 6, rather than 4, so server
receives next request 64 s later, which is 1984 s before smearing
starts, so server would *not* send "poll 4" this time, but send the
received poll value back to the client.

3.) Since the server didn't send "poll 4" this time but drift seems to
be close to 0, the clients increases its polling interval to 7, so the
server receives the next request 128 s later, i.e. 1856 s before
smearing starts. The server again does *not* send "poll 4" since
smearing starts more than 2 * 128 s in the future.

4.) So the client eventually increases its polling interval once more,
until in a worst case it has ramped up again to a high value and sends
the next request only after smearing has already started.

So this doesn't sound very reliable. The server would have to track the
state for each client to get it right and remember it had already
started sending "poll 4" to this client. However, basically we don't
want the server to have to keep track of the client state (I know, it
does if rate management is active), and this would require quite some
execution time to look up the state, update the state, and send an
appropriate poll value to each client.

So personally I'd try to keep things simpler and let the server send
"poll 4" (or whichever value seems to be appropriate) to each client,
starting a certain time interval before smearing starts.

Martin