(Emacs: -*- indented-text -*-)

		      Installation Instructions
			    for PPSkit-2.0
		      Copyright (c) 1997 - 2001
			   by Ulrich Windl

0) Unpack a compatible version of the Linux kernel sources (if not
   already done).  The kernel version should match the version of the
   patch (e.g. `patch-2.0.31pre9' matches `linux-2.0.31pre9').  Make
   sure that you have the tools and resources needed for a kernel
   compilation (see /usr/src/linux/Documentation/Changes).

   If you compiled a kernel before, you should do a `make mrproper' to
   clean up before patching.

1) The patches against the kernel follow the usual convention, that is
   you need `-p1' if your are standing in your kernel directory.
   Apply the patch as usual (e.g. cd /usr/src/linux; patch -p1 <the_patch).
   If your patch program does produce a lot of output, maybe check for
   rejects using `find . -name '*.rej' -print'.  If your patch leaves
   backups of original files behind, you may want to execute
   `find . -name '*.orig' | xargs rm'.

2a) Use `make config' and enable `experimental drivers' to see the PPS
    option.

2b) Select `NTP kernel support', `NTP PPS support', and `NTP PPS
    support on serial port' after selecting the serial driver.  The
    driver can be inserted as a module at runtime if you like.

3a) `make dep' and then make the kernel (and modules) as usual
    (e.g. `make bzImage')

3b) OPTIONAL: Have a small break with coffee, tee, cookies, or whatever...

4a) Activate the new kernel (copy the files and modules into place,
    maybe edit /etc/lilo.conf, and re-run LILO) and reboot (as
    usual)...

4b) If you have built the serial driver as a module, load that module
    (`insmod serial.o' if it isn't done automatically) and be sure
    that the `PPSAPI' option is displayed (or logged).  The string
    should read similar to ``Serial driver version 5.05+ with
    PPS_API(RFC-2783) enabled''.

4c) Make sure the right include files for the C compiler are found and
    used: The patch creates new files "timepps.h", and "timex.h" in
    ``$LINUX/include/linux'' (where ``$LINUX'' is your source directory.
    Despite of discussions whether files in /usr/include/sys should be the
    current kernel's versions, I simply state:

    If you intend to use ntpd with PPS support, you'll have to make a
    symbolic link for each of the files mentioned above.  Maybe you
    want to backup the original timex.h file.

    (e.g.	for i in timepps.h timex.h
		do
			ln -s $LINUX/include/linux/$i /usr/include/sys/$i
		done
    )

    Remember to repeat this step whenever you upgrade your C library
    or include files (overwrite ``<sys/timex.h>'' to be specific).

5) Do whatever you like ;-) If you use ntpd, be sure to get a recent
   version like ntp-4.0.99f (ntp-4.0.98b is the first release to
   support the draft "05" of the PPS API, hacked rather quickly using
   the FreeBSD implementation.  So be prepared for surprises and
   incompatibilities.)  You can set up the PPS API using ``ppsctl'' if
   the daemon fails to do so. Just make sure the port remains opened).

   [The details of PPS/ATOM configuration and monitoring are described
   in the NTP FAQ]

   For ntpd-4.0.98a the ATOM driver worked out-of-the-box.  But you'll
   have to remove config.cache, do re-configure, and recompile ntpd to
   get PPS support into the daemon.  You should configure the ATOM
   reference clock in addition to your usual clocks.

   You must recompile ntpd 4.0 to work correctly with the new kernel.
   Binaries compiled with the standard kernel will show strange effects
   (see the NTP FAQ for details).  Recent versions seem to have some
   limited auto-detection capabilities however, so they might even work.

   When everything is working, the ``ATOM'' (``PPS'') clock will become
   ``PPS peer'' (`o') after some time if the preferred peer has been chosen
   as primary synchronization source, and the PPS signal has been monitored
   to be good enough.

   With ntpd-4.0 the flag ``STA_PPSFREQ'' should go on once the
   preferred time source is reachable and seems valid.  If the jitter
   is low enough, or if the offset is small enough, ``STA_PPSTIME''
   will also go on.

   Maybe after a while your loopstats file will look like this:
51791 75053.799 0.000000609 16.613007 0.000013035 0.009817 6
51791 75119.800 -0.000000286 16.614990 0.000011292 0.008559 6
51791 75185.801 0.000000192 16.614990 0.000009781 0.007413 6
51791 75249.802 -0.000000460 16.613998 0.000008473 0.006439 6
51791 75313.804 0.000000138 16.613998 0.000007342 0.005576 6
51791 75379.805 0.000000020 16.608047 0.000006371 0.005672 6
51791 75443.806 -0.000000158 16.608047 0.000005532 0.004912 6
