Kai-Steffen Hielscher 28/03/02
|
|
|
|
Kai-Steffen Hielscher 28/03/02
|
| PPS API |
| The PPS API specified in RFC 2783 is an extention of the kernel clock model that can be used to timestamp external events with the kernel clock. If an external source of timestamps with a precise frequency and a defined time offset to some universal time scale such as UTC is available, these timestamps can be used to discipline the kernel clock.. A good source of such timestamps is our GPS receiver system. The timestamps generated have a high frequency stability and are specified to be less then 500ns off to the beginning of the UTC second. Since one signal is generated every second, the whole system is called PPS: pulse-per-second. But receiving PPS pulses is not enough to discipline the clock: The system cannot know the beginning of which second in which minute, hour or even day, month and year the pulse marks. To provide no ambiguity the system must be synchronized to an external time source with a time offset of less than half a second to make sense of the PPS pulses. We use a standard NTP server over the network to do this. The timestamps generated by the PPS API can be used by the kernel directly (hardpps) or by a driver for NTP (ATOM driver) to discipline the kernel clock. We also measured some stability estimators of the undisciplined local clocks. |
| NANO-Kenel |
| While Linux provides the kernel model for precision timekeeping (RFC 1589), it has no support for the PPS-API and the resolution of the kernel clock is restricted to microseconds. The NANO patch developed by Ulrich Windl extends the resolution of the kernel clock to nanoseconds and provides PPS API support. It contains a modification of the serial port driver that allows the serial port to receive PPS pulses while still beeing usable for general purpose serial communications. We implemented an experimental PPS driver for the parallel port. Since this driver does not allow any other communications on the same port, we were able to get slightly lower latency and jitter. (During the development of the driver we noticed problems generated by spurious interrupts 7.) |
| Results |
| Using
a combination of NTP over the network and PPS pulses over the serial port
we synchronized the clocks of the systems to have time differences less
than 25µs. To prove this, we conducted longtime measurements with
the ZM4 hardware monitor developed at our institute. The unsynchronized clocks of our machines had frequency offsets of at most 37ppm. This seems small, but an unsynchronized system with such an error is nearly 3.2 seconds off per day. |
| Contact |
| Dipl.-Inf.
Kai-Steffen Hielscher |