[LinuxPPS] New LinuxPPS user intro

[Hal V. Engel]

On Thursday 18 September 2008 02:19:53 am Luca Bertagnolio wrote:
> >> if that is the case, then I suppose I could try an earlier kernel, like
> >> 2.6.24 o 25 using the quinquies patch
> >
> >Nak, just use the _latest_ LinuxPPS version.
>
> my suggestion was more due to the glibc bug flagged by Hal.  If this issue
> surfaced with 2.6.26, I might try to go back one or two versions, that's
> why I mentioned going back to a previous patch.
>
> >LinuxPPS has been changed several times during its life due several
> >problems regarding its internal API. Testing older versions may
> >generate problems not related with PPS issues.

The kernel is stable.  What happens is that with out the glibc patches ntpd 
does not work as well as it could/should but at a level that is sub 
millisecond in nature.  In addition, most of this can be fixed by simply 
patching /usr/include/sys/timex.h (this is 95% of the glibc patch) and 
rebuilding ntp.   This is what most of us have been doing since we didn't know 
about the glibc patch until yesterday (IE. we had a patch for sys/times.h).  
Thank you William for pointing out the patch to us.

Some Gentoo specific stuff.  In <glibc-2.7, at least on amd64 machines, gentoo 
placed the actual sys/timex.h in /usr/include/gentoo-
multilib/<arch>/sys/timex.h and /usr/include/sys/timex.h contained only arch 
specific includes to /usr/include/gentoo-multilib/<arch>/sys/timex.h.  This is 
changed as of glibc-2.7 and it now uses /usr/include/sys/timex.h for all 
arches.  I am going to try to put together an ebuild for a fully patched 
glibc-2.7.  When I have that working I will post it to the bug report and let 
this list know.  This will allow gentoo users to build a patched version of 
glibc-2.7 for testing.

>
> fair enough.  I just wanted to avoid having both an unstable kernel and
> unstable PPS code... But I guess that this is what testing is about!
>
> >> One last thing, I noticed that ppstest fails if tried after stopping
> >> ntpd:
> >
> > Can you please enable DEBUGing messages?

Also you might want to modify your /etc/init.d/ntpd file so that ppsldisc is 
killed either as part of starting the daemon or in the code that stops the 
daemon.  I found that I had issues with this much like what you are seeing 
before I did that.   

Here is what I did (this is from the howto I am working on):

In the existing /etc/init.d/ntpd script you should have a section that looks 
like this:
start() {
checkconfig || return $?
	start-stop-daemon --start --exec /usr/sbin/ntpd \
		--pidfile /var/run/ntpd.pid \
		-- -p /var/run/ntpd.pid ${NTPD_OPTS}
	eend $? "Failed to start ntpd"
}

To have this script handle the ppsldisc correctly it needs to be modified to 
look something like this:
start() {
	checkconfig || return $?
	ebegin "Starting ntpd"
	/<where ever you installed this file>/ppsldisc /dev/ttyS1 & pid=$? 
	start-stop-daemon --start --exec /usr/sbin/ntpd \
		--pidfile /var/run/ntpd.pid \
		-- -p /var/run/ntpd.pid ${NTPD_OPTS}
	eend $? "Failed to start ntpd"
	sleep 30 
	killall ppsldisc 
}

This keeps ppsldisc running long enough for ntp to startup and then kills it.  
I think 30 seconds may be way longer than it needs.


>
> recompiling just now, I can test from remote and will let you know.  But
> compiling a kernel on a Pentium MMX 200 might take a while!  

And building glibc takes way longer than the kernel.

> Luckily this
> is just minor diffs, but if I need to recompile from scratch I open the box
> and connect the HD to faster machine to recomiple, then move the HD back to
> the MMX! ;-)
>
> Ciao, Luca
>
> _______________________________________________
> LinuxPPS mailing list
> LinuxPPS at ml.enneenne.com
> http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
> Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support