On 2013-12-07, Magnus Danielson wrote:
> On 12/07/2013 01:17 AM, unruh wrote:
>> On 2013-12-06, Magnus Danielson wrote:
>>> On 12/06/2013 10:53 AM, Harlan Stenn wrote:
mike cook writes:
>> If you know the drift file is unreliable, you should delete it. ntpd
>> will then perform a fr
On 12/07/2013 01:17 AM, unruh wrote:
> On 2013-12-06, Magnus Danielson wrote:
>> On 12/06/2013 10:53 AM, Harlan Stenn wrote:
>>> mike cook writes:
> If you know the drift file is unreliable, you should delete it. ntpd
> will then perform a frequency calibration before entering the main
>>
On 2013-12-06, Magnus Danielson wrote:
> On 12/06/2013 10:53 AM, Harlan Stenn wrote:
>> mike cook writes:
If you know the drift file is unreliable, you should delete it. ntpd
will then perform a frequency calibration before entering the main
loop. ...
>>> This is what has been reco
On 12/06/2013 10:53 AM, Harlan Stenn wrote:
> mike cook writes:
>>> If you know the drift file is unreliable, you should delete it. ntpd
>>> will then perform a frequency calibration before entering the main
>>> loop. ...
>> This is what has been recommended for ages but it doesn't completely
>> f
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 is a ntpd running, that synchronized to other ntp servers.
A system goes f
Hi, all--
On Dec 6, 2013, at 4:13 AM, Martin Burnicki wrote:
> Agreed. If ntpd would do initial corrections faster we wouldn't even need a
> drift file, and it didn't matter if an OS kernel computed slightly different
> clock frequencies each time the system reboots.
Unless your computer's qua
On 2013-12-06, Brian Inglis wrote:
> It would be better if ntpd used the drift file frequency for the first
> two hours, instead of 15 minutes, before coming up with its (currently
> wild assed) guesstimate, and then spending 4 hours getting back to the
> drift frequency.
I do not think you under
On 06/12/2013 13:15, Brian Inglis wrote:
[]
I have automated the saving and restoring of drift files with good values
to replace drift files with bad values at startup, as the calibration on
Windows is way off, and it's often quicker to restart than wait many hours
ordays.
Possibly because MS dis
On 06/12/2013 09:42, Jos van de Ven wrote:
[]
http://www.synclab.org/?tag=raspberry%20pi
Quote:
The Raspberry Pi does not ship with a TSC or HPET counter to use as clocksource. Instead
it relies on the STC that raspbian presents as a clocksource. Based on the source code,
"STC: a free running
In article <99gou.413035$ur1.286...@fx19.iad>, unruh wrote:
>On 2013-12-06, Bruce Evans wrote:
>> ...
>> To handle the calibration varying across reboots, under FreeBSD I just
>> blow away the system calibration using a sysctl in an etc/rc file.
>> FreeBSD never had large variance in TSC calibra
Op 6 dec. 2013, om 09:47 heeft unruh het volgende geschreven:
> On 2013-12-06, David Taylor wrote:
>> On 04/12/2013 21:25, Terje Mathisen wrote:
>> []
>>> It is very common, IF you are running on Linux!
>>>
>>> The base frequency is recalculated each time you restart, which means
>>> that step
On 2013-12-05 11:58, David Woolley wrote:
On 05/12/13 14:24, mike cook wrote:
The problem for ntp is that ntp takes a long time to recover from a bad
drift value.
This seems to have been an issue since I started using ntp, more than 10 years
ago. I am surprised that it is not fixed.
If y
It would be better if ntpd used the drift file frequency for the first
two hours, instead of 15 minutes, before coming up with its (currently
wild assed) guesstimate, and then spending 4 hours getting back to the
drift frequency.
This is on Windows 7, current stable ntpd, NMEA user mode pps ref c
Hello,
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 is a ntpd running, that synchronized to other ntp servers.
I can write a simple bash script that does this (saving to an intermed
mike cook wrote:
Le 5 déc. 2013 à 19:58, David Woolley a écrit :
If you know the drift file is unreliable, you should delete it.
ntpd will then perform a frequency calibration before entering the
main loop. Otherwise it starts on the basis that the drift value
is good and it is seeing measureme
On Fri, Dec 06, 2013 at 10:17:48AM +, David Taylor wrote:
> On 06/12/2013 09:36, Harlan Stenn wrote:
> []
> >The only systems we've seen that did this are Linux kernels, and it
> >would be good to get the starting and ending dates/kernel numbers for
> >this behavior.
> >
> >H
>
> The only data
On 06/12/2013 09:36, Harlan Stenn wrote:
[]
The only systems we've seen that did this are Linux kernels, and it
would be good to get the starting and ending dates/kernel numbers for
this behavior.
H
The only data points I can contribute to that are that 3.2.27 and 3.6.11
appear to be OK, at l
You might be able to do better. In QC an average of a randomly gathered
sample of a continuous variable is distributed as normal (Gaussian).
If NTPD kept a few more statistics (state), it could measure the freq
and determine if it is outside of 3 standard deviations of the grand
mean of past obse
Le 6 déc. 2013 à 10:53, Harlan Stenn a écrit :
> mike cook writes:
>>> If you know the drift file is unreliable, you should delete it. ntpd
>>> will then perform a frequency calibration before entering the main
>>> loop. ...
>>
>> This is what has been recommended for ages but it doesn't comple
mike cook writes:
>> If you know the drift file is unreliable, you should delete it. ntpd
>> will then perform a frequency calibration before entering the main
>> loop. ...
>
> This is what has been recommended for ages but it doesn't completely
> fix the issue. It still takes a long time to sett
Le 5 déc. 2013 à 19:58, David Woolley a écrit :
> On 05/12/13 14:24, mike cook wrote:
>>>
>>>
>>> The problem for ntp is that ntp takes a long time to recover from a bad
>>> drift value.
>>>
>>
>> This seems to have been an issue since I started using ntp, more than 10
>> years ago. I am sur
David Taylor writes:
> On 06/12/2013 08:47, unruh wrote:
> []
> > As I said, I think that in the more recent kernels Linux has fixed this.
> > Since the RPi is only about 2 years old, its linux is a recent kernel.
>
> The one I've used are Linux 3.2.27 or 3.6.11. However, one poster also
> menti
On 06/12/2013 08:47, unruh wrote:
[]
As I said, I think that in the more recent kernels Linux has fixed this.
Since the RPi is only about 2 years old, its linux is a recent kernel.
The one I've used are Linux 3.2.27 or 3.6.11. However, one poster also
mentioned the problem is FreeBSD, althoug
On 2013-12-06, Bruce Evans wrote:
> In article , unruh
> wrote:
>>On 2013-12-05, antonio.marchese...@gmail.com
>> wrote:
>>>
>>> I understand and I apologise but I'm with a small netbook at the
>>moment and I can't do better. I'm trying to clean the posts before
>>posting them back.
>>>
>>> I'l
On 2013-12-06, David Taylor wrote:
> On 04/12/2013 21:25, Terje Mathisen wrote:
> []
>> It is very common, IF you are running on Linux!
>>
>> The base frequency is recalculated each time you restart, which means
>> that steps of 100-200 ppm from one reboot to the next can be expected.
>>
>> Terje
25 matches
Mail list logo
