On the alpha, asm-alpha/param.h defines __KERNEL_HZ to 1024 which is
fine, so tick being the number of uS between clock updates is
977. (well it should be ~977.5 but...).
However, which means that a single unit change in tick alters the
speed of the clock by 1024ppm. Again this isn't a real problem, but
linux/timex.h defines MAXFREQ as
#define MAXFREQ (200L << SHIFT_USEC) /* max frequency error (ppm) */
so the kernel pll will not permit the frequence to be changed by more
than +/- 200ppm. I think this should be (2 * HZ)ppm. If this is a
really bad idea please let me know! Can this be added to 2.0.34 (and
2.1.x if appropriate)?
My poor little alpha clocks arn't within 200ppm so the clock adjust
can't cope, and altering the tick doesn't help as it isn't that far
out!
As an aside can anyone tell me a good reason why ntp_adjtime() and
ntp_gettime() are not implemented in glibc (2.0.7 and earlier don't
have them). Not putting them in libc makes xntpd3 have to work much
harder to use the kernel-pll (xntp3-5.93 won't detect it at all on my
alphas without much hackery. I can provide trivial wrappers to
__adjtimex() if anyone wants them. When I reported the problems to the
xntpd maintainers they suggested I switch to FreeBSD!
-- Jon Peatfield, DAMTP, Computer Officer, University of Cambridge Telephone: +44 1223 3 37852 Mail: J.S.Peatfield@damtp.cam.ac.uk- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu