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 _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
