On Friday, December 6, 2013 11:53:02 PM UTC+1, David Woolley wrote:
On 06/12/13 12:13, Patrik Arlos wrote:
[ Very long lines! ]
I have a C program that needs to evaluate the system (where it runs)
clock synchronization status on a regular interval(every ~60s). On the
same system there
On 07/12/13 11:54, Patrik Arlos wrote:
On Friday, December 6, 2013 11:53:02 PM UTC+1, David Woolley wrote:
The program just needs to keep track/detect when the synchronization is lost.
Its used to correlate measurements at multiple locations, and the measurements
include time. So, as long
Magnus Danielson writes:
The drift-file-accelerated lock-in isn't robust. Current behavior of
response isn't very useful for most people experiencing it.
I'm not sure I'd agree with the word most. It's certainly worked very
well on hundreds of machines where I've run it, and the feedback I've
unruh writes:
As I said, get chrony if you want much faster convergence, if you want
better control of the time offset from UTC, and if yourun Linux or
BSD.
And this begs the question of faster convergence towards *what*?
NTP looks a a number of time sources, finds a majority clique that
Patrik Arlos writes:
Is there a C api for ntpq? or is the only solution to read the ntpq
code, and extract the needed 'bits'?
See libntpq. If somebody was to contribute a man page for that I'd add
it to the distribution.
H
___
questions mailing
On 2013-12-07, Harlan Stenn st...@ntp.org wrote:
unruh writes:
As I said, get chrony if you want much faster convergence, if you want
better control of the time offset from UTC, and if yourun Linux or
BSD.
And this begs the question of faster convergence towards *what*?
UTC :-)
NTP looks
Hello all,
I've got another strange issue with NTP. Last week I found that the logs
were not populating anymore, last entry was a few days before.
Stopped the NTP service, deleted the log file and restarted the service
fixed it.
Today found that the log file is not populating again.
As
On 12/07/2013 11:39 PM, Harlan Stenn wrote:
Magnus Danielson writes:
The drift-file-accelerated lock-in isn't robust. Current behavior of
response isn't very useful for most people experiencing it.
I'm not sure I'd agree with the word most. It's certainly worked very
well on hundreds of
ntp ntp3140 2013-12-07 15:49 loopstats.20131207
I do not know how you are reading the files to see if it not populating
them?
Thanks
Antonio
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
unruh writes:
On 2013-12-07, Harlan Stenn st...@ntp.org wrote:
unruh writes:
As I said, get chrony if you want much faster convergence, if you want
better control of the time offset from UTC, and if yourun Linux or
BSD.
And this begs the question of faster convergence towards *what*?
On 2013-12-08, Harlan Stenn st...@ntp.org wrote:
unruh writes:
On 2013-12-07, Harlan Stenn st...@ntp.org wrote:
unruh writes:
As I said, get chrony if you want much faster convergence, if you want
better control of the time offset from UTC, and if yourun Linux or
BSD.
And this begs
11 matches
Mail list logo
