Messages in this thread | | | Subject | Problem with kernel-pll in 2.0.3x (at least) | From | Jon Peatfield <> | Date | 30 Apr 1998 23:37:23 +0100 |
| |
I just found a problem with the kernel-pll in 2.0.34pre10 (well it hasn't changed since at least 2.0.33 as far as I can tell). It only affects Alpha hardware (though it would affect anything which has __KERNEL_HZ set to a value much larger than 100).
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
| |