Hey all,

I've been experimenting with Linux kernel settings with respect to how they
affect ntpd as I understand for the gps18lvc to work effectively, one needs
a fairly accurate clock.  One thing I've found is with hz=100, I'm getting
an ntp.drift of around 40 but with a fairly good rootdispersion at stratum 2
of approx 15.  With hz=250, the frequency drift drops to 15 but dispersion
and jitter rise.  Finally, I tried the high-res timers patch with and
without dynamic ticks.  The hr-timers have frequency at 0.039but the jitter
reported by ntpq -p on peers is still higher than a vanilla kernel with
hz=100.

So my question is should the drift be varying so much based on kernel hz and
why would there be increased jitter with a reduced frequency error?  Has
anyone else tried the hrtimers patch and had good results?

Shane

In article <%Z1zh.913733$1T2.858211@pd7urf2no>,
shane-dated-1173632795.f2b9df@cm.nu wrote:

>             as I understand for the gps18lvc to work effectively, one needs
> a fairly accurate clock.  One thing I've found is with hz=100, I'm getting

Which Linux a achieves by interpolating the clock interrupts by reading
the CPU TSC register.  You do not need to increase the tick frequency
to improve accuracy, unless your PPS interface operates on a timer tick
poll, in which case you are never going to get the best accuracy.

> an ntp.drift of around 40 but with a fairly good rootdispersion at stratum 2
> of approx 15.  With hz=250, the frequency drift drops to 15 but dispersion

Let me guess. The clock gains when uncorrected.  The change in frequency
is due to the increased number of lost clock interrupts.  You do not
want any lost interrupts at all.

> So my question is should the drift be varying so much based on kernel hz and

It should be independent of frequency, except in that there might be a very
small increase in case temperature.

> why would there be increased jitter with a reduced frequency error?  Has

Firstly don't think of it as frequency error; it is a frequency
correction that is nulling out the original error in the motherboard
crystal frequency.  As long as this value is stable and less than about
+/- 450 ppm (to allow some head room for short term adjustments), it
doesn't matter what it is.  In fact, if the sign of the correction was
the opposite, and the lost interrupt hypothesis is valid, the magnitude
would have increased.

The reason the jitter increases is that every time you lose a clock
interrupt, you get a 4ms (at 250Hz) step in the apparent time.

> anyone else tried the hrtimers patch and had good results?

I don't know anything except what you have written, but from that, I would
think they would thoroughly confuse ntpd.  The near zero correction
looks very suspicious.  Getting a motherboard with a clock that is
accurate to 40 ppb would be very remarkable (probably less than 1% 
probability).

shane,

Firt, you can't use the kernel discipline if the clock runs other than 
100 Hz. The Linux kernel apparently does not adjust the kernel phase and 
frequency coefficients for other that 100 Hz. I have reports that the 
coefficients have been re-engineered for higher clock frequencies and 
NTP is happy.

Second, I suspect the kernel adjtime() system call does not correct the 
slew rate to 500 PPM when the clock frequency is changed. This is not 
hard to do and requires changing only one define that sets the number of 
microseconds or nanoseconds adjusted at each tick.

I conclude running an unmodifed Linux kernel at other than 100 Hz with 
NTP is a lose.

Dave

shane-dated-1173632795.f2b9df@cm.nu wrote:
> Hey all,
> 
> I've been experimenting with Linux kernel settings with respect to how they
> affect ntpd as I understand for the gps18lvc to work effectively, one needs
> a fairly accurate clock.  One thing I've found is with hz=100, I'm getting
> an ntp.drift of around 40 but with a fairly good rootdispersion at stratum 2
> of approx 15.  With hz=250, the frequency drift drops to 15 but dispersion
> and jitter rise.  Finally, I tried the high-res timers patch with and
> without dynamic ticks.  The hr-timers have frequency at 0.039but the jitter
> reported by ntpq -p on peers is still higher than a vanilla kernel with
> hz=100.
> 
> So my question is should the drift be varying so much based on kernel hz and
> why would there be increased jitter with a reduced frequency error?  Has
> anyone else tried the hrtimers patch and had good results?
> 
> Shane
> 

Please consider adding this information to http://ntp.isc.org/Support .

If you want a hand with it just let me know.

H

shane,

As I have said before, there are two issues with Linux and clock 
frequencies other than 100 Hz. First, if the kernel discipline is used, 
the phase and frequency parameters have to be changed. Othewise, the 
feedback loop dynamic response will go nuts. Second, the slew rate of 
the Unix tickadj() system call needs to be changed to preserve the 
assumed slew rate of 500 PPM. The Linux kernelmongers probably know this 
but so far have not made the necessary changes.

So, if you change to other than 100 Hz, do not use the kernel discipline 
at all. Second, be prepared for some grief using the ntpd discipline 
loop. The only other advice I can give is use FreeBSD instead.

Dave

shane-dated-1173632795.f2b9df@cm.nu wrote:
> Hey all,
> 
> I've been experimenting with Linux kernel settings with respect to how they
> affect ntpd as I understand for the gps18lvc to work effectively, one needs
> a fairly accurate clock.  One thing I've found is with hz=100, I'm getting
> an ntp.drift of around 40 but with a fairly good rootdispersion at stratum 2
> of approx 15.  With hz=250, the frequency drift drops to 15 but dispersion
> and jitter rise.  Finally, I tried the high-res timers patch with and
> without dynamic ticks.  The hr-timers have frequency at 0.039but the jitter
> reported by ntpq -p on peers is still higher than a vanilla kernel with
> hz=100.
> 
> So my question is should the drift be varying so much based on kernel hz and
> why would there be increased jitter with a reduced frequency error?  Has
> anyone else tried the hrtimers patch and had good results?
> 
> Shane
> 

In article <eqstit$gjm$1@scrotar.nss.udel.edu>, mills@udel.edu wrote:

> feedback loop dynamic response will go nuts. Second, the slew rate of 
> the Unix tickadj() system call needs to be changed to preserve the 
> assumed slew rate of 500 PPM. The Linux kernelmongers probably know this 
> but so far have not made the necessary changes.

The last time that I looked at the code, this was done, but, like
ntpq, subject to a "precision" of only one microsecond.  That means
that the slew rate will be 500ppm for clock periods that are a multiple
of 2ms, i.e. 100 Hz, 125Hz, 166.666666.... Hz, 250Hz, and 500Hz.  Of
these, apart from 100Hz, only 250Hz is sometimes used, but 1000Hz is
rather more common, and doesn't have an integral number of microseconds
per tick that will achieve 500ppm.  (I'm not sure if the repeating 
decimal frequency can actually be configured acurately, though.)

> So, if you change to other than 100 Hz, do not use the kernel discipline 

This is referring to the first of Dave Mills' comments.

> at all. Second, be prepared for some grief using the ntpd discipline 
> loop. 

This is referring to the slew rate issue.