[LinuxPPS] Recommendation / Re: Stats & architectures
clemens at dwf.com
clemens at dwf.com
Tue Mar 18 00:06:23 CET 2008
> clemens at dwf.com wrote:
> >> Rodolfo Giometti wrote:
> >>> I suppose you shouldn't need to much efforts in getting the HARDPPS
> >>> support from Ulrich Windl's code and move it into LinuxPPS.
> >> What benefit(s) does HARDPPS support bring?
> >>
> > Well, you would expect that having the kernel itself detect the time
> > differences
> > from its clock to the pps signal would result in a 'tighter' control of the
> > clock
> > than the ntpd (userspace) code doing this and then passing this information to
> > the kernel using the adjtime system call.
> >
> > With a clock with (only) microsecond resolution, and an adjtime system call
> > with only microsecond resolution one has to expect that the clock frequency/
> > phase is zig-zagging around the 'correct' value a lot more than if these were
> > both configured in nanoseconds. The HARDPPS support would put the entire
> > ntp calculation in the kernel, thus at least the adjtime system call is no
> > longer
> > relevant.
>
>
> I modified kernel/time/ntp.c to use a smaller time constant and to use the pps
> time stamp directly instead of the offset fed to it by ntp when the offset goes
> below 50 milliseconds. The kernel time constant modification because I don't
> like how badly modern linux kernels follow the pps for me and using the pps
> directly was me wanting to see how hard it was to get something basic working
> after staying up late Friday night catching up with this list and reading this
> thread.
>
> Linuxpps uses getnstimeofday() so a nanosecond time stamp is available.
I hate to break it to you, but if you look at the kernel code, getnstimeofday is a dmy
routine,- it just multiplies the us value by 1000 and returns it. It does NO interpolation.
That DOES mean that you dont have to change code when a REAL ns clock becomes
available, but thats about it...
--
Reg.Clemens
reg at dwf.com
More information about the LinuxPPS
mailing list