Messages in this thread |  | | From | "Ulrich Windl" <> | Date | Fri, 29 Nov 1996 08:30:26 +0100 | Subject | new NTP/PPS patch available |
| |
Hello,
yesterday I decided to make a more recent patch for kernel PPS support. The patch is now against 2.0.26, but the previous version also worked. The patch can be found in /pub/wiu09524/PPS/design.tar.gz on pcphy4.physik.uni-regensburg.de.
I also updated the serial driver to make Ted sleep again (he was worried a lot about calling do_gettimeoffset() from within the serial interrupt routine). I still call do_gettimeoffset() from within interrupt, but only if PPS detection is enabled on the corresponding port, and the reason for the interrupt was a PPS pulse. I hope that Ted is satisfied.
Now the do_gettimeoffset just has to be correct (I hope it is).
As several people wanted to play with that patch, I'll give a very short summary (HOWTO):
You have to apply the patch (of course), then you have to reconfigure the kernel using "experimental features". After the serial driver there is a new option about "PPS support"; use that. (The current patch can't make the serial driver as a module, because I didn't know how to export an additional symbol scorrectly for module use. Help anybody?) Rebuild the kernel, install it and reboot.
One really ugly sample program (enable_PPS.c) tries to turn on PPS detection for stdin; that only works if you redirect your serial port (enable_PPS </dev/cua1). The program periodically outputs some essential data about the kernel clock state. Also, if you terminate the program the PPS detection is turned off again (close seems to restore the drivers state).
Ok, you are read now. You just need a PPS pulse. If you don't have a frequency oscillator, you might use the second ugly program (rtctest3.c) that uses the independent RTC to generate a PPS pulse on one serial port (RTS pin as far as I remember). You just need a cable to feed the RTS output to the CD input of your "PPS port" (connect the ground too, please). The latter ugly program wants to have two arguments, serial port names. The first will be used to create the output pule, the second is almost unused, but needs to be given (thus an ugly program).
If it works you should be getting serial interrupts (two per second, but one is ignored) and the 0x100 bit in the clock status should be set immediately. After a while (12 seconds) the PPS frequency should change for the first time and the shift constant should increase. Stability should go down below 10ppm at least.
For use with xntp you should leave the serial port with the PPS pulse alone (with enable_PPS.c running). xntpd knows _nothing_ about HOW the PPS signal arrives in the kernel; it just recognizes that it is there and what effects it causes.
For the electric levels required: about +-2V with a duration of a few microseconds should do (the serial interrupt is generated upon level change, but the level has to be sustained until the interrupt routine can read the current level; the level is not latched. Right, Ted?)
I don't know exactly what the exact stability of the PPS signal has to be, but it's rumoured that it should be off less than 1ms per second.
Up to now I could not test anything better than the RTC solution, because at work where there is a PPS signal with 50microseconds precision I have no Linux box close to the signal...
To my understanding the code works just fine. Opposite proofs appreciated!
Ulrich Windl
|  |