[LinuxPPS] oncore almost working

[clemens at dwf.com]

I replied to this question directly to Martin, I meant to send it to
the list also.  There have been a recent discussion about HARDPPS,
my reply to Martin is relevant to that discussion.  Basically, ignore
this option, its not going to help you and only makes the kernel
code more complex.
                                                 Reg.C.


> Hi.
> 
> I think this is mostly for Reg Clemens, but everyones input
> would be much appreciated.
> 
> I've patched my kernel and everything seems to be
> working. With my oncore gps hooked up (I have a CNS clock
> with the UT (or UT+ ?) chipset), I am getting the pulses as
> can be see with the ppstest program:
> 
> root at refclock2:/usr/src/linux/drivers/pps# ppstest 
> found PPS source #0 "serial0" on "/dev/ttyS0"
> ok, found 1 source(s), now start fetching data...
> source 0 - assert 1178833769.951610156, sequence: 43 - clear
> 1178834100.142258797, sequence: 45
> source 0 - assert 1178834100.943780854, sequence: 44 - clear
> 1178834100.142258797, sequence: 45
> source 0 - assert 1178834100.943780854, sequence: 44 - clear
> 1178834101.142291417, sequence: 46
> source 0 - assert 1178834101.943756940, sequence: 45 - clear
> 1178834101.142291417, sequence: 46
> source 0 - assert 1178834101.943756940, sequence: 45 - clear
> 1178834102.142323697, sequence: 47
> source 0 - assert 1178834102.943733178, sequence: 46 - clear
> 1178834102.142323697, sequence: 47
> 
> I will write up the process I went through for my
> distribution and post it somewhere if people think it would
> be usefull.
> 
> 
> My problem is that in my /etc/ntp.oncore0 I had
> HARDPPS... this does not work with the current PPSkit, and
> it worked with the 2.4 series patches.
> 
> The oncore driver bails when then kernel module tells it
> that the PPS_KC_HARDPPS is not supported.
> 
> I've read around, and I think I want HARDPPS, but I am not
> sure I totally understand what is going on... in particular
> with the new patch.
> 
> Back with the 2.4 kernel patches, the PPS_KC_HARDPPS was
> supported. What did it do? What did specifying HARDPPS in
> the oncore configuration file mean?
> 
> By not supporting it in the 2.6 patch, is there going to be
> a different behavior?
> 
> I'll start looking through the 2.4 patches to see if I can
> understand what is going on... but in the meantime, if
> anyone knows what is going on :D.
> 
> What I want is my systems clock to be conditioned by ntp
> with the gps so it has a better idea of how long a second
> really is.
> 
> 
> Thanks so much!
> 
> Martin.

Sounds like you have things working.
I have some fixes for the code at the top of refclock_oncore.c.
What is there worked a year ago, but it doesnt choose the requested device
with things today.  I *think* I have it right now, but was waiting for Rodolfo 
to
put out some descriptions of what his functions do before moving my 
changes into the ntp source..  Im guessing I understand, but would like
to know for sure what some of these things do...

As for HARDPPS.
It causes a call to time_pps_kcbind.
With the kernel changes that Dave proposed, and that Ulrich followed in
the 2.4 series of PPSKit, there was the ntp engine in the ntpd routine in
userland, that preened the clock using system calls, and there was a 2nd
equivalent engine built into the Linux/Unix/whatever kernel.  If you did
the kcbind thing, you handed off the work from the userland code to the
kernel code.

In *theory* this was better, but had a larger footprint in the kernel.
It would seem that in *fact*, with the fast kernels that we have today, that
it really doesnt make any difference.  So not having kcbind is no big 
deal.  You/we should be getting the same accuracy.

Now if we could get back the nanosecond clock that Ulrich had installed
throughout the kernel, that would be nice.


-- 
                                        Reg.Clemens
                                        reg at dwf.com