Miroslav Lichvar wrote:
On Mon, Jan 26, 2015 at 06:45:58PM +0100, Terje Mathisen wrote:
Miroslav Lichvar wrote:
Here is a test showing error between two clients of a server
smearing.a large offset. With the cosine function you can see a large
spike when smearing started.
https://mlichvar.fedorapeople.org/tmp/smear_cos.png
https://mlichvar.fedorapeople.org/tmp/smear_sinx.png
This seems wrong!?!
First of all, you seem to extend the smearing over a million seconds or so?
I.e. 10-15 days?
Yes.
How large is the adjustment to be smeared out?
10000 seconds. It was a test to see how useful is smearing when
bringing an isolated network back to UTC in a controlled manner.
10K seconds in 1M seconds corresponds to a steering rate of 1:100 or 10K
ppm, i.e. 20 times higher than the maximum ntpd adjustment rate.
How would you expect it to work under those conditions?
The google cosine approach starts with a derivate of zero and ends the same
way, I really can't see how that leads to that huge (more than 128 ms!)
spike at the start?
The frequency is changing too quickly at start (2nd derivative is at
the maximum) and the clients don't have a chance to shorten their polling
interval to better track the server.
The point is that there are better functions than cosine for this.
OK, when the adjustment is way outside the control range for ntpd, then
you are obviously correct: ntpd, either with or without smearing, is not
the best tool. :-)
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
