[LinuxPPS] Patches for kernel 2.6.26-rc8

[Hal V. Engel]

On Sunday 06 July 2008 09:39:24 am Bernhard Schiffner wrote:
> On Sunday 06 July 2008 18:03:36 Hal V. Engel wrote:
> > On Sunday 06 July 2008 08:52:54 am Hal V. Engel wrote:
> > > On Sunday 06 July 2008 07:14:15 am Bernhard Schiffner wrote:
> > > > On Sunday 06 July 2008 10:31:38 Hal V. Engel wrote:
> > > > ...
> > > >
> > > > > Second ntp appears to be running in microsecond mode rather than
> > > > > nanosecond mode even though I built it against the new kernel
> > > > > header files.  When I run ntptime I get:
> > > > >
> > > > >
> > > > > ntp_gettime() returns code 0 (OK)
> > > > >   time cc1a25a4.f3dc6000  Sat, Jul  5 2008  9:53:56.952, (.952581),
> > > >
> > > > Ther are (small but important) differerences between
> > > > /usr/include/linux and /usr/src/kernel/include/linux.
> > > > One is what the distributor cleaned up for your use, working with a
> > > > lot of different kernels too. The other is the recent opinion of the
> > > > kernel-community.
> > > > Test this please to get it right.
> > >
> > > What should I test?  Are you saying that I should build ntp without the
> > > symlinked directories?  I will give that a try.
>
> Perhaps I said it the wrong way.
>
> To make a ntpd working with ns-resolution (your primary concern) you need a
> ntpd compiled with _consideration_ of the kernel variable STA_NANO.
> (STA_NANO will come with linux 2.6.26. Make sure it is set in your
> environment accordingly.)
>
> If have to do the ntpd compilation yourself, make sure to reach the same
> status as mentioned above.
>
> > This did not work.  If I build ntp without the symlinked directories in
> > /usr/include it will not work with the PPS device.
>
> Wrong :-(
> Sometimes it is important to have access to the latest and greatest
> kernel-defines.
> You'll find them under ($KERNELSOURCE)/include/linux/.
> Your distributor usually makes a "strange" copy of this directory and
> provides it as /usr/include/linux.
> Diff these two directories to see their differences. Find your opinion
> about this. (Is STA_NANO accesssible?)
>
> One simple way to get rid of the differences is to move /usr/include/linux
> to an other place for later restore, delete /usr/include/linux and create a
> symlink instead (ln -s  ($KERNELSOURCE)/include/linux  /usr/src/linux).
>
> Don't delete symlinks in /usr/include ...
>
> I hope this explanation helps.
> (Perhaps I find some time to come into this business myself again.)
>
> Bernhard


Orginally I was thinking that I could add the STA_NANO and other related 
defines to the kernel/sys/timex.h file in the ntp source tree.   But this did 
not work even though the build requires this file to exist (why if it does not 
use it?).  I found that it was picking up the other related defines such as 
STA_FLL in 


/usr/include/sys/timex.h 


which is redirected to


/usr/include/gentoo-multilib/amd64/sys/timex.h


I added the needed defines to it (probably not the best way to handle this) 
and I now have a working NANO ntp.


$ ntptime
ntp_gettime() returns code 0 (OK)
  time cc1bc2ff.cec3974c  Sun, Jul  6 2008 15:17:35.807, (.807672320),
  maximum error 5235 us, estimated error 1 us
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset -0.083 us, frequency -24.157 ppm, interval 1 s,
  maximum error 5235 us, estimated error 1 us,
  status 0x2001 (PLL,NANO),
  time constant 4, precision 0.001 us, tolerance 500 ppm,


This is taking longer to sync then my previous setups but at this point it is 
acting like it will sync since the rate that the clock is moving toward 0 
offset is very gradual.  The above ntptime command was run just after it had 
crossed 0 offset for the first time after restart which took about two hours.


Hal


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.enneenne.com/pipermail/linuxpps/attachments/20080706/e9d09da3/attachment.htm