Harlan,
On 03/06/2015 10:35 AM, Harlan Stenn wrote:
Folks,
A while ago we got a request from the embedded folks asking for a way to
limit the writing of the drift file unless there was a "big enough"
change in the value to warrant this.
Somebody came up with an interesting way to do this that involves
looking to see how much the drift value has changed and only writing the
value if the change was "big enough".
By my read of the code and the comments:
1) it looks like the code is implementing something other than what the
comments want, and
2) what's described *or* implemented seems way more complicated than
what we need.
I'm wondering if we should just let folks specify a drift/wander
threshold, and if the current value is more than that amount we write
the file, and if the current value is less than that amount we don't
bother updating the file. If folks are on a filesystem where the number
of writes doesn't matter, no value would be set (or we could use 0.0)
and it's not an issue.
Thoughts?
For embedded systems, reducing the rate of writing make sense, so in
this regard the question is valid IMHO.
There can't be a universal limit that will once and for all satisfy all
needs, so some user configurability would make sense.
Another aspect is that if a drift-file exists, NTP believes it and skip
the frequency track-in phase and does not resolve the resulting constant
reset of time that will be a result of not being able to track in the
difference between the given offset and actual offset, if it is too
large (this addresses Jochen's 3rd point about worst case scenario). I
discovered this the hard way some years back, but I think it never got
resolved. Anyway, as long as this misfeature remains, lowering the
drift-write rate could lead to subtle misconfiguration issues worse than
existing drift-file issues. This would limit the range of values users
could configure and it would also end up expose the existing misfeature
since we need to make sure that there is a very high likelihood that the
drift-value written is within the capture range of the PLL mode, even
when written more seldom.
Trying to modify the way NTP write (Joochen's point 1) does not help for
flashes, it's the write itself which may be long-term destruction, so it
is reducing the rate of write which should be the key. It might be
better to do the write as part of shut-down.
In general, the drift-file handling should be made more fool-proof
first, before attempting to improve the write rate issue. It has already
proven itself causing a number for problems, but rather than addressing
it directly, trying to address triggers seems to be the main problem.
Until this is done, the drift-file can be a beneficial accelerator for
systems where it works, but may be discouraged for other system uses.
It's main motivation is to overcome the FLL phase time of NTP start-up.
Cheers,
Magnus
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
