Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.sai.msu.su/~er/xntp/driver8.html
Дата изменения: Unknown Дата индексирования: Sat Dec 22 01:48:57 2007 Кодировка: Поисковые слова: cygnus loop |
Address: 127.127.8.u
Reference ID: PARSE
Driver ID: GENERIC
Serial Port: /dev/refclock-u
; 9600 baud, 8-
bits, no parity
Features: ppsclock
The timecode of these receivers is sampled via a STREAMS module in the kernel (The STREAMS module has been designed for use with SUN Systems under SunOS 4.1.x. It can be linked directly into the kernel or loaded via the loadable driver mechanism). This STREAMS module can be adapted to be able to convert different time code formats. If the daemon is compiled without the STREAM definition synchronization will work without the Sun streams module, though accuracy is significantly degraded.
The actual receiver status is mapped into various synchronization states generally used by receivers. The STREAMS module is configured to interpret the time codes of DCF U/A 31, PZF535, GPS166, Trimble SV6 GPS, ELV DCF7000, Schmid and low cost receivers (see list below).
The reference clock support in xntp contains the necessary configuration tables for those receivers. In addition to supporting up to 32 different clock types and 4 devices, the generation a a PPS signal is also provided as an configuration option. The PPS configuration option uses the receiver generated time stamps for feeding the PPS loopfilter control for much finer clock synchronization.
CAUTION: The PPS configuration option is different from the hardware PPS signal, which is also supported (see below), as it controls the way xntpd is synchronized to the reference clock, while the hardware PPS signal controls the way time offsets are determined.
The use of the PPS option requires receivers with an accuracy of better than 1ms.
Fudge factors
Only two fudge factors are utilized. The time1 fudge factor defines the phase offset of the synchronization character to the actual time. On the availability of PPS information the time2 fudge factor defines the skew between the PPS time stamp and the receiver timestamp of the PPS signal. This parameter is usually zero, as usually the PPS signal is believed in time and OS delays should be corrected in the machine specific section of the kernel driver. time2 needs only be set when the actual PPS signal is delayed for some reason. The flag0 enables input filtering. This a median filter with continuous sampling. The flag1 selects averaging of the samples remaining after the filtering. Leap secondhandling is controlled with the flag2. When set a leap second will be deleted on receipt of a leap second indication from the receiver. Otherwise the leap second will be added, (which is the default).
ntpq (8)
timecode variable
The ntpq program can read clock variables command list several variables. These hold the following information: refclock_time is the local time with the offset to UTC (format HHMM). The currently active receiver flags are listed in refclock_status. Additional feature flags of the receiver are optionally listed in parentheses. The actual time code is listed in timecode. A qualification of the decoded time code format is following in refclock_format. The last piece of information is the overall running time and the accumulated times for the clock event states in refclock_states. When PPS information is present additional variable are available. refclock_ppstime lists then the PPS timestamp and refclock_ppsskew lists the difference between RS232 derived timestamp and the PPS timestamp.
Unit encoding
The unit field encodes the device, clock type and the PPS generation option. There are 4 possible units, which are encoded in the lower two bits of the field. The devices are named /dev/refclock-0 through /dev/refclock-3. Bits 2 thru 6 encode the clock type. The fudge factors of the clock type are taken from a table clockinfo in refclock_parse.c. The generation of PPS information for disciplining the local NTP clock is encoded in bit 7 of .
Currently, nine clock types (devices /dev/refclock-0 - /dev/refclock- 3) are supported.
127.127.8.0-3 16 Meinberg PZF535 receiver (FM demodulation/TCXO /
50us)
127.127.8.4-7 16 Meinberg PZF535 receiver (FM demodulation/OCXO /
50us)
127.127.8.8-11 16 Meinberg DCF U/A 31 receiver (AM demodulation /
4ms)
127.127.8.12-15 16 ELV DCF7000 (sloppy AM demodulation / 50ms)
127.127.8.16-19 16 Walter Schmid DCF receiver Kit (AM demodulation /
1ms)
127.127.8.20-23 16 RAW DCF77 100/200ms pulses (Conrad DCF77 receiver
module / 5ms)
127.127.8.24-27 16 RAW DCF77 100/200ms pulses (TimeBrick DCF77
receiver module / 5ms)
127.127.8.28-31 16 Meinberg GPS166 receiver (GPS / <<1us)
127.127.8.32-35 16 Trimble SV6 GPS receiver (GPS / <<1us)
The reference clock support carefully monitors the state transitions of the receiver. All state changes and exceptional events such as loss of time code transmission are logged via the syslog facility. Every hour a summary of the accumulated times for the clock states is listed via syslog.
PPS support is only available when the receiver is completely synchronized. The receiver is believed to deliver correct time for an additional period of time after losing synchronizations, unless a disruption in time code transmission is detected (possible power loss). The trust period is dependent on the receiver oscillator and thus a function of clock type. This is one of the parameters in the clockinfo field of the reference clock implementation. This parameter cannot be configured by xntpdc.
In addition to the PPS loopfilter control a true PPS hardware signal can be applied on Sun Sparc stations via the CPU serial ports on the CD pin. This signal is automatically detected and will be used for offset calculation. The input signal must be the time mark for the following time code. (The edge sensitivity can be selected - look into the appropriate kernel/parsestreams.c for details). Meinberg receivers can be connected by feeding the PPS pulse of the receiver via a 1488 level converter to Pin 8 (CD) of a Sun serial zs\-port.
There exists a special firmware release for the PZF535 Meinberg receivers. This release (PZFUERL 4.6 (or higher - The UERL is important)) is absolutely recommended for XNTP use, as it provides LEAP warning, time code time zone information and alternate antenna indication. Please check with Meinberg for this firmware release. For the Meinberg GPS166 receiver is also a special firmware release available (Uni-Erlangen). This release must be used for proper operation.
The raw DCF77 pulses can be fed via a level converter directly into Pin 3 (Rx) of the Sun. The telegrams will be decoded an used for synchronization. AM DCF77 receivers are running as low as $25. The accuracy is dependent on the receiver and is somewhere between 2ms (expensive) to 10ms (cheap). Upon bad signal reception of DCF77 synchronizations will cease as no backup oscillator is available as usually found in other reference clock receivers. So it is important to have a good place for the DCF77 antenna. For transmitter shutdowns you are out of luck unless you have other NTP servers with alternate time sources available.
When enabled by the flag4
fudge flag, every received
timecode is written as-is to the clockstats
file.
time1 time
time2 time
stratum number
refid string
PARSE
.
flag1 0 | 1
flag2 0 | 1
flag3 0 | 1
flag4 0 | 1
clockstats
recording if set.