[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-hackers
Subject:    Re: [ntp:hackers] Solaris TIOSPPS
From:       "David L. Mills" <mills () udel ! edu>
Date:       2004-03-08 16:23:57
Message-ID: 404C9E1D.E0B8C14D () udel ! edu
[Download RAW message or body]

Reg,

I can't tell you how many scrapes and bruises I've had on the PPSAPI
issue. The mantra spoken many, many times is that the ONLY way to
support the PPS function is PPSAPI. I carefully built timepps.h header
files for a number of different machines, including SunOS, Solaris,
FreeBSD, Tru64 and verified they all worked a year or so ago, hoping
these would be the models for other machines. Apparently, lots of folks
disregarded these models and struck off on different paths.

As further background, we once had a terrible mess of hokey schemes for
PPS involving a very tricky combination of streams modules, line
disciplines and rickety interface code that was different for each
operating system. The climate was very much like the politics of Iraq;
the Shiites worshipped line disciplines, the Sunni worshipped streams
modules, the Kurds worshipped in-driver, machine-dependent interface and
the Turkomans worshipped an old table-driven conversion between Unix
timeval and NTP time format. Somehow I don't think the civil war has
completely abated.

Meanwhile, let's get rid of anything and everything spurious and worship
the timepps.h interface. Furthermore, lets get rid of all PPS-dependent
code in all the drivers. Check me out with the following agenda. We add
an optional behavior in the atom driver. The current behavior is to
disable the PPS unless the serial timecode is within the step range. If
so, switch the discipline to the atom driver where the seconds are
determined from the prefer peer.

In the current NMEA-type drivers the serial timecode labels the second
on which the PPS is struct, so can be anything up to a second before the
PPS, so the strategy in those drivers is to replace the fraction field
with the PPS and, in this case, the atom driver is superfluous. But, the
atom driver perfoems a very useful function in that the PPS can be
processed by a 60-stage median-filter/trimmed-mean grooming function,
which reduces jitter by a factor of one-sixth, besides doing the
mitigation thing.

In principle, it would not be hard at all to do this in the atom driver;
however, if the large residual jitter in the serial timecode were to
remain, the clusting algorithm would probably toss the sucker out should
other sources be in contention. So, the atom driver would have to lie
and force the driver seconds value to match the PPS. Ugly, but not
different than what is done now.

Turns out in most cases seen here the atom driver with the nanokernel
produces less jitter than when the PPS signal is piped directly to the
kernel. I found this rather surprising, and as the result defaulted the
PPS to the driver rather than the kernel.

Would you like to have a crack at that? We would want to make the method
of selecting the scheme automatic, even when drivers of either
persuasion are present. One approach is to make the reference ID for
NMEA drivers NMEA and the others GPS. Any other suggestions?

Dave 

reg@dwf.com wrote:
> 
> >
> > I was tuning up some refclock and driver code and tripped over the
> > PPSAPI code and Solaris 8. I haven't used it in Solaris for a couple of
> > years. I copied the timepps.h from the solaris directory in the
> > nanokernel distribution to /usr/include/sys as I have done many times
> > before, and rebuilt from scratch. First off, the refclock_oncore.c
> > failed to compile due to apparent conflicting interfaces. Patched that
> > out and build succeeded.
> >
> > On startup the atom driver failed a call to TIOSPPS, which is the first
> > time that happened to me. Just to be sure, I checked the oncore driver
> > and found it uses the same calling sequence as the atom driver. This
> > code used to work at least so far as I remember in Solaris 7.
> >
> 
> Dave:-
> 
> You bring up a couple of things here, perhaps if you respond, I could
> simplify the ONCORE driver.
> 
> First a bit of recent history.
> 
> Back at the beginning of February I had a user complain that he couldnt
> get the ONCORE driver to work with Solaris8.  After some work with him,
> and resurecting my old Sparc2 with Solaris7 (I think) on it, we (I) discovered
> that when you did a cleanup of the refclock_open code (it needed it) back
> about a year ago, the initialization call to TIOCSPPS had disappeared.
> I added that to the ONCORE driver, and if memory serves, there was one other
> problem,- namely: with the contents of all of the current *.h files the
> code was choosing the PPSAPI path thru the #includes, even tho Solaris
> didnt have a PPSAPI.  I also fixed the #ifdefs, and at that point the
> driver worked on both my machine and his (tho he is down in a canyon and
> it took a while before the oncore saw enough satellites to be happy...)
> 
> OK, you mention your 'timepps.h' file from the nanokernel code.  I just
> looked at it, and I wrote something similar back when we were first
> converting the drivers over to the PPSAPI.  I still have a directory
> that contains (timepps-SunOS4, timepps-sco, timepps-solaris, timepps-freebsd)
> plus a few other variants.
> 
> I looked at your refclock_atom, and although there are #ifdefs in it for
> the PPSAPI, it looks like it ONLY works for the PPSAPI.  Is that true?
> 
> OK, my real question.
> I think, having the drivers written to ONLY use the PPSAPI (throwing out
> a lot if #ifdefs, and a some (if not a lot) of confusing code would make
> the code a lot cleaner.  We would then support machines without the PPSAPI
> with copies of timepps.h like yours for Solaris (or the ones I had for
> other machines).  Doesn't see that we loose anyting, and the code is
> cleaner.
> 
> What would be required is a few additional comments added to the current
> documentation (html) directory, and a subdirectory somewhere with the
> modified timepps.h routines in it.  If a user were on Solaris (or whatever)
> s/he could either copy the timepps.h routine into /usr/include/sys/
> (or whatever) or the config program could be smart enought to get it from
> where it was saved in the ntp distribution (nicer).
> 
> So, I would REALLY like to move this Solaris code out of the ONCORE driver
> and into a timepps.h, but since it is somewhat of a global change that
> other drivers should adhere to too, I would like to hear you say yes or no.
> 
> As for your final question:
> 
> >
> > Does anybody have PPSAPI working in recent Solaris (8, 9). Has the
> > TIOSPPS ioctl bben changed? Is there documentation on the TIOCSPPS?
> >
> 
> Im going to assume that where you type TIOSPPS you mean TIOCSPPS.
> Yes the ONCORE driver is working with Solaris7/8 with its BUILT IN calls,
> it would take a day or two to see if it works with the PPSSAPI built into
> the timepps.h routines, I can fire up my sparc2 (again) tommorow and give
> it a shot.
> 
> As for documentation, Ive never seen any,- and about two months ago
> I sure looked...
> 
> --
>                                         Reg.Clemens
>                                         reg@dwf.com
_______________________________________________
hackers mailing list
hackers@ntp.org
http://mailman.ntp.org/mailman/listinfo/hackers
[prev in list] [next in list] [prev in thread] [next in thread]