True, it would be nice to remove the systematic error, but unless the way that
the code is written is changed completely you still need to allow freq to
extent up to HZ (plus a bit of slack) ppm.
[ that is if the code still uses tick = 1000000/HZ and tick is an integer ]
We could define everything in terms of nS or pS (if we have enough bits to
play with), to reduce the possibility of systematic error...
> Definitely that's a bug! tickadj can't be zero, because the time can't
> adjust then. Fortunately there's an extended adjtimex call to modify
> tickadj without even rebooting (if you have the patch...my patch).
That probably explains why xntpd using an external pll seemed unable to alter
the system clock! (Which is why I went looking at trying to make it use the
kernel-pll in the first place).
-- Jon
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu