Hi guys!
I have a machine running FreeBSD 7.4 and it seems that the CPU clock runs
too fast or slow (positive offset in loopstats is fast or slow?).
tick# tail -10 /var/log/ntp/loopstats
55829 66814.311 0.10871 185.398 0.03540 0.002317 4
55829 66831.312 0.10025 185.398 0.00984 0.0
Miguel Gonçalves wrote:
I have a machine running FreeBSD 7.4 and it seems that the CPU clock runs
too fast or slow (positive offset in loopstats is fast or slow?).
Neither. A constant sign on an offset is an indication that something
is broken, either the algorithm, or the static frquency er
2011/9/25 Miguel Gonçalves :
> I have a machine running FreeBSD 7.4 and it seems that the CPU clock runs
> too fast or slow (positive offset in loopstats is fast or slow?).
ntpd's offset and the frequency compensation are both reported as
corrections to the local clock to bring it into alignment w
2011/9/25 Dave Hart :
> 2011/9/25 Miguel Gonçalves :
>
>> tick# tail -10 /var/log/ntp/loopstats
>> 55829 66814.311 0.10871 185.398 0.03540 0.002317 4
>> 55829 66831.312 0.10025 185.398 0.00984 0.002167 4
>> 55829 66847.312 0.11242 185.398 0.01303 0.002027 4
>> 55829 66862.31
[Sorry for such a long message]
Hi David!
On 25 September 2011 20:55, David Woolley wrote:
> Miguel Gonçalves wrote:
>
>>
>> I have a machine running FreeBSD 7.4 and it seems that the CPU clock runs
>> too fast or slow (positive offset in loopstats is fast or slow?).
>>
>
> Neither. A constant
Hi Dave!
2011/9/26 Dave Hart
> 2011/9/25 Miguel Gonçalves :
> > I have a machine running FreeBSD 7.4 and it seems that the CPU clock runs
> > too fast or slow (positive offset in loopstats is fast or slow?).
>
> ntpd's offset and the frequency compensation are both reported as
> corrections to t
2011/9/26 Dave Hart
> 2011/9/25 Dave Hart :
> > 2011/9/25 Miguel Gonçalves :
> >
> >> tick# tail -10 /var/log/ntp/loopstats
> >> 55829 66927.314 0.11263 185.398 0.00620 0.001452 4
> >> 55829 66942.315 0.11355 185.398 0.00402 0.001358 4
> >> 55829 66957.315 0.10197 185.398 0.00
Miguel Gonçalves wrote:
What is a typical offset of the loop without using special oscillators? Is
less than 1 us achievable?
Depends on the network or reference clock, and the resolution to which
the local clock can be read.
___
questions mailing
On 9/26/2011 9:41 AM, Miguel Gonçalves wrote:
2011/9/26 Dave Hart
2011/9/25 Dave Hart:
2011/9/25 Miguel Gonçalves:
tick# tail -10 /var/log/ntp/loopstats
55829 66927.314 0.11263 185.398 0.00620 0.001452 4
55829 66942.315 0.11355 185.398 0.00402 0.001358 4
55829 66957.315 0.000
Hi Richard!
On 26 September 2011 22:39, Richard B. Gilbert wrote:
>
> What is a typical offset of the loop without using special oscillators? Is
>> less than 1 us achievable?
>>
>
> I don't believe that accuracy of 1 microsecond , or less, is obtainable
> without without installing a GPS Timing R
Just a small correction...
2011/9/27 Miguel Gonçalves
>
> Your chances of obtaining 1 microsecond accuracy using clocks on the
>> internet is just about nil! OTOH very few people actually need
>> microsecond accuracy for anything other than "bragging rights"!
>>
>
> I know... :-) My cable connec
2011/9/26 Miguel Gonçalves :
> 2011/9/26 Dave Hart
>> 2011/9/25 Miguel Gonçalves :
>> > I have a machine running FreeBSD 7.4 and it seems that the CPU clock
>> > runs
>> > too fast or slow (positive offset in loopstats is fast or slow?).
>>
>> ntpd's offset and the frequency compensation are both
On 2011-09-26, Miguel Gon?alves wrote:
> Hi Richard!
>
> On 26 September 2011 22:39, Richard B. Gilbert wrote:
>>
>> What is a typical offset of the loop without using special oscillators? Is
>>> less than 1 us achievable?
>>>
>>
>> I don't believe that accuracy of 1 microsecond , or less, is obt
In article ,
David Woolley writes:
>Miguel Gon=E7alves wrote:
>> What is a typical offset of the loop without using special oscillators?
>> Is less than 1 us achievable?
>Depends on the network or reference clock, and the resolution to which
>the local clock can be read.
It also depends upon t
Richard B. Gilbert wrote:
I don't believe that accuracy of 1 microsecond , or less, is obtainable
without without installing a GPS Timing Receiver or an atomic clock of
some sort.
He asked for an offset of 1 microsecond (presumably RMS or 90
percentile?), not an accuracy of 1 microsecond.
Miguel Gonçalves wrote:
Besides correcting the CPU clock frequency what can I do to improve the
Applying a static correction to the clock frequency only helps if the
static error is close to or greater than 500ppm. However, if that is
the case, the right thing to do is to replace the mothe
On 27 September 2011 01:29, unruh wrote:
> Any(?) gps receiver which has PPS output does better than 1us. Any
> network does much worse than 1 us ( more like 10s of us to hundreds).
>
I might be wrong but checking for instance the Garmin 18 LVC specifications
(http://www8.garmin.com/products/gp
On 27 September 2011 10:35, David Woolley wrote:
> Applying a static correction to the clock frequency only helps if the
> static error is close to or greater than 500ppm. However, if that is the
> case, the right thing to do is to replace the motherboard, with a better one
> as it is likely tha
On Mon, Sep 26, 2011 at 02:29:42PM +0100, Miguel Gonçalves wrote:
> So... I was getting around 180 ppm frequency offset in /etc/ntp.drift and
> this value also appeared in loopstats file.
>
> I checked the machdep.tsc_freq value (this is estimated at boot but can be
> changed after the boot comple
On Tue, Sep 27, 2011 at 10:20:57AM +0100, David Woolley wrote:
> Richard B. Gilbert wrote:
>
> >
> >I don't believe that accuracy of 1 microsecond , or less, is
> >obtainable without without installing a GPS Timing Receiver or an
> >atomic clock of some sort.
>
> He asked for an offset of 1 micro
On 2011-09-27, Miguel Gon?alves wrote:
> One had 180 ppm sand the other 46 ppm without fiddling with machdep.tsc_freq
> sysctl variable. After the correction I am getting -0.041 ppm for the first
> and -0.045 ppm for the second.
>
>
> Embedded machines running NanoBSD and they don't do anything el
2011/9/27 Miguel Gonçalves :
> 2011/9/27 Dave Hart
>>
>> I think you're simply confused. The FreeBSD sysctl you modified isn't
>> adjusting the TSC frequency. It's adjusting FreeBSD's estimate of the
>> TSC frequency. I stand by my understanding that a positive frequency
>> compensation reporte
22 matches
Mail list logo