Bancomm bc635VME Time and Frequency Processor

From: Harlan Stenn Date: Fri, 15 Oct 2010 06:56:35 +0000 (-0400) Subject: Documentation updates from Dave Mills X-Git-Tag: NTP_4_2_7P64~2 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=269707ea81ae10d4340af06e7923227dd40524b0;p=thirdparty%2Fntp.git Documentation updates from Dave Mills bk: 4cb7fb23pG-HgMjJ1qZrlSgMSwN95g --- diff --git a/html/authopt.html b/html/authopt.html index eb8088db4..8d6e23dc9 100644 --- a/html/authopt.html +++ b/html/authopt.html @@ -17,7 +17,7 @@ color: #FF0000; gif

from Alice's Adventures in Wonderland, Lewis Carroll

Our resident cryptographer; now you see him, now you don't.

Last update: - 02-Oct-2010 23:55 + 14-Oct-2010 22:27 UTC

Auxiliary Commands

broadcastclient: Enable reception of broadcast server messages to any local interface (type b address). Ordinarily, upon receiving a broadcast message for the first time, the broadcast client measures the nominal server propagation delay using a brief client/server exchange, after which it continues in listen-only mode. If a nonzero value is specified in the broadcastdelay command, the value becomes the delay and the volley is not executed. Note: the novolley option has been deprecated for future enhancements. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric key or public key authentication as described in the Authentication Options page. Note that the novolley keyword is incompatible with public key authentication.
manycastserver address [...]: Enable reception of manycast client messages (type m)to the multicasts group address(es) (type m) specified. At least one address is required. Note that, in order to avoid accidental or malicious disruption, both the server and client should operate using symmetric key or public key authentication as described in the Authentication Options page.; Enable reception of broadcast server messages to any local interface (type b address). Ordinarily, upon receiving a broadcast message for the first time, the broadcast client measures the nominal server propagation delay using a brief client/server exchange, after which it continues in listen-only mode. If a nonzero value is specified in the broadcastdelay command, the value becomes the delay and the volley is not executed. Note: the novolley option has been deprecated for future enhancements. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric key or public key authentication as described in the Authentication Options page. Note that the volley is required with public key authentication in order to run the Autokey protocol..
manycastserver address [...]: Enable reception of manycast client messages (type m) to the multicasts group address(es) (type m) specified. At least one address is required. Note that, in order to avoid accidental or malicious disruption, both the server and client should operate using symmetric key or public key authentication as described in the Authentication Options page.
multicastclient address [...]: Enable reception of multicast server messages to the multicast group address(es) (type m) specified. Upon receiving a message for the first time, the multicast client measures the nominal server propagation delay using a brief client/server exchange with the server, then enters the broadcast client mode, in which it synchronizes to succeeding multicast messages. Note that, in order to avoid accidental or malicious disruption in this mode, both the server and client should operate using symmetric key or public key authentication as described in the Authentication Options page.

diff --git a/html/decode.html b/html/decode.html index 009a8404c..afede786e 100644 --- a/html/decode.html +++ b/html/decode.html @@ -11,7 +11,7 @@ gif

from Alice's Adventures in Wonderland, Lewis Carroll

Caterpillar knows all the error codes, which is more than most of us do.

Last update: - 14-Oct-2010 3:34 + 14-Oct-2010 16:31 UTC

Kiss Codes

diff --git a/html/drivers/driver16.html b/html/drivers/driver16.html index 95308ba16..a054fcd9a 100644 --- a/html/drivers/driver16.html +++ b/html/drivers/driver16.html @@ -2,30 +2,30 @@ - - - - - Bancomm bc635VME Time and Frequency Processor - - + + + + + Bancomm bc635VME Time and Frequency Processor + + - -

bc635VME/bc350VXI Time and Frequency Processor

Synopsis

Address: 127.127.16.u
- Reference ID: BTFP
- Driver ID: GPS_BANCOMM
- Bancomm Device /dev/btfp0
- Requires: Bancomm bc635 TFP device module driver for SunOS 4.x/SunOS 5.x

Description

This is the clock driver for the Bancomm bc635VME Time and Frequency Processor. It requires the BANCOMM bc635VME bc350VXI Time and Frequency Processor Module Driver for SunOS 4.x/SunOS 5.x UNIX Systems.

Most of this code is originally from refclock_bancomm.c with thanks. It has been modified and tested on an UltraSparc IIi-cEngine running Solaris 2.6. A port for HPUX is not available henceforth.

Additional Information

Reference Clock Drivers

- - + +

bc635VME/bc350VXI Time and Frequency Processor

Synopsis

Address: 127.127.16.u
+ Reference ID: BTFP
+ Driver ID: GPS_BANCOMM
+ Bancomm Device /dev/btfp0
+ Requires: Bancomm bc635 TFP device module driver for SunOS 4.x/SunOS 5.x

Description

Most of this code is originally from refclock_bancomm.c with thanks. It has been modified and tested on an UltraSparc IIi-cEngine running Solaris 2.6. A port for HPUX is not available henceforth.

Additional Information

Reference Clock Drivers

+ + \ No newline at end of file diff --git a/html/drivers/driver2.html b/html/drivers/driver2.html index 20bad64a2..50af737e6 100644 --- a/html/drivers/driver2.html +++ b/html/drivers/driver2.html @@ -2,28 +2,28 @@ - - - - Trak 8820 GPS Receiver - - + + + + Trak 8820 GPS Receiver + + - -

Trak 8820 GPS Receiver

Synopsis

Address: 127.127.2.u
- Reference ID: GPS
- Driver ID: GPS_TRAK
- Serial Port: /dev/traku; 9600 baud, 8-bits, no parity
- Features: tty_clk

Description

This driver supports the Trak 8820 GPS Station Clock. The claimed accuracy at the 1-PPS output is 200-300 ns relative to the broadcast signal; however, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system.

For best accuracy, this radio requires the tty_clk line discipline, which captures a timestamp at the * on-time character of the timecode. Using this discipline the jitter is in the order of 1 ms and systematic error about 0.5 ms. If unavailable, the buffer timestamp is used, which is captured at the \r ending the timecode message. This introduces a systematic error of 23 character times, or about 24 ms at 9600 bps, together with a jitter well over 8 ms on Sun IPC-class machines.

Using the menus, the radio should be set for 9600 bps, one stop bit and no parity. It should be set to operate in computer (no echo) mode. The timecode format includes neither the year nor leap-second warning.

In operation, this driver sends a RQTS\r request to the radio at initialization in order to put it in continuous time output mode. The radio then sends the following message once each second:

*RQTS U,ddd:hh:mm:ss.0,q<cr><lf>
+	
+		Trak 8820 GPS Receiver
+		
+		Synopsis
+		Address: 127.127.2.u

+			Reference ID: GPS

+			Driver ID: GPS_TRAK

+			Serial Port: /dev/traku; 9600 baud, 8-bits, no parity

+			Features: tty_clk
+		Description
+		This driver supports the Trak 8820 GPS Station Clock. The claimed accuracy at the 1-PPS output is 200-300 ns relative to the broadcast signal; however, in most cases the actual accuracy is limited by the precision of the timecode and the latencies of the serial interface and operating system.
+		For best accuracy, this radio requires the tty_clk line discipline, which captures a timestamp at the * on-time character of the timecode. Using this discipline the jitter is in the order of 1 ms and systematic error about 0.5 ms. If unavailable, the buffer timestamp is used, which is captured at the \r ending the timecode message. This introduces a systematic error of 23 character times, or about 24 ms at 9600 bps, together with a jitter well over 8 ms on Sun IPC-class machines.
+		Using the menus, the radio should be set for 9600 bps, one stop bit and no parity. It should be set to operate in computer (no echo) mode. The timecode format includes neither the year nor leap-second warning.
+		In operation, this driver sends a RQTS\r request to the radio at initialization in order to put it in continuous time output mode. The radio then sends the following message once each second:
+		*RQTS U,ddd:hh:mm:ss.0,q<cr><lf>
 on-time = '*'
 ddd = day of year
 hh:mm:ss = hours, minutes, seconds
@@ -34,34 +34,34 @@ q = quality indicator (phase error), 0-6:
      4 > 100 ns
      3 > 10 ns
      2 < 10 ns
-        The alarm condition is indicated by 0 at Q, which means the radio has a phase error greater than 20 us relative to the broadcast time. The absence of year, DST and leap-second warning in this format is also alarmed.
-        The continuous time mode is disabled using the RQTX\r request, following which the radio sends a RQTX DONE<cr><lf> response. In the normal mode, other control and status requests are effective, including the leap-second status request RQLS<cr>. The radio responds with RQLS yy,mm,dd<cr><lf>, where yy,mm,dd are the year, month and day. Presumably, this gives the epoch of the next leap second, RQLS 00,00,00 if none is specified in the GPS message. Specified in this form, the information is generally useless and is ignored by the driver.
-        Monitor Data
-        When enabled by the flag4 fudge flag, every received timecode is written as-is to the clockstats file.
-        Fudge Factors
-        
-        
-            time1 time
-            
Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
-            
time2 time
-            
Not used by this driver.
-            
stratum number
-            
Specifies the driver stratum, in decimal from 0 to 15, with default 0.
-            
refid string
-            
Specifies the driver reference identifier, an ASCII string from one to four characters, with default GPS.
-            
flag1 0 | 1
-            
Not used by this driver.
-            
flag2 0 | 1
-            
Not used by this driver.
-            
flag3 0 | 1
-            
Not used by this driver.
-            
flag4 0 | 1
-            
Not used by this driver.
-            Additional Information
-            Reference Clock Drivers
-        
-        
-        
-    
+		The alarm condition is indicated by 0 at Q, which means the radio has a phase error greater than 20 us relative to the broadcast time. The absence of year, DST and leap-second warning in this format is also alarmed.
+		The continuous time mode is disabled using the RQTX\r request, following which the radio sends a RQTX DONE<cr><lf> response. In the normal mode, other control and status requests are effective, including the leap-second status request RQLS<cr>. The radio responds with RQLS yy,mm,dd<cr><lf>, where yy,mm,dd are the year, month and day. Presumably, this gives the epoch of the next leap second, RQLS 00,00,00 if none is specified in the GPS message. Specified in this form, the information is generally useless and is ignored by the driver.
+		Monitor Data
+		When enabled by the flag4 fudge flag, every received timecode is written as-is to the clockstats file.
+		Fudge Factors
+		
+		
+			time1 time
+			
Specifies the time offset calibration factor, in seconds and fraction, with default 0.0.
+			
time2 time
+			
Not used by this driver.
+			
stratum number
+			
Specifies the driver stratum, in decimal from 0 to 15, with default 0.
+			
refid string
+			
Specifies the driver reference identifier, an ASCII string from one to four characters, with default GPS.
+			
flag1 0 | 1
+			
Not used by this driver.
+			
flag2 0 | 1
+			
Not used by this driver.
+			
flag3 0 | 1
+			
Not used by this driver.
+			
flag4 0 | 1
+			
Not used by this driver.
+				Additional Information
+				Reference Clock Drivers
+		
+		
+		
+	
 
 
\ No newline at end of file
diff --git a/html/drivers/driver5.html b/html/drivers/driver5.html
index 1b539acaa..cad7a0368 100644
--- a/html/drivers/driver5.html
+++ b/html/drivers/driver5.html
@@ -2,71 +2,71 @@
 
 
 
-    
-        
-        TrueTime GPS/GOES/OMEGA Receivers
-        
-    
+	
+		
+		TrueTime GPS/GOES/OMEGA Receivers
+		
+	
 
-    
-        TrueTime GPS/GOES/OMEGA Receivers
-        
-        Synopsis
-        Address: 127.127.5.u

-        Reference ID: GPS, OMEGA, GOES

-        Driver ID: TRUETIME

-        Serial Port: /dev/trueu; 9600 baud, 8-bits, no parity

-        Features: tty_clk
-        Description
-        This driver supports several models models of Kinemetrics/TrueTime timing receivers, including 468-DC MK III GOES Synchronized Clock, GPS- DC MK III and GPS/TM-TMD GPS Synchronized Clock, XL-DC (a 151-602-210, reported by the driver as a GPS/TM-TMD), GPS-800 TCU (an 805-957 with the RS232 Talker/Listener module), OM-DC OMEGA Synchronized Clock, and very likely others in the same model family that use the same timecode formats.
-        Most of this code is originally from refclock_wwvb.c with thanks. It has been so mangled that wwvb is not a recognizable ancestor.
-        Timcode format: ADDD:HH:MM:SSQCL A - control A (this is stripped before we see it) Q - Quality indication (see below) C - Carriage return L - Line feed Quality codes indicate possible error of
-        
-            468-DC GOES Receiver

-                GPS-TM/TMD Receiver
-            
? +/- 500 milliseconds # +/- 50 milliseconds

-                * +/- 5 milliseconds . +/- 1 millisecond

-                space less than 1 millisecond
-            
OM-DC OMEGA Receiver:
-            
> +/- 5 seconds

-                ? +/- 500 milliseconds # +/- 50 milliseconds

-                * +/- 5 milliseconds . +/- 1 millisecond

-                A-H less than 1 millisecond. Character indicates which station is being received as follows

-                A = Norway, B = Liberia, C = Hawaii, D = North Dakota, E = La Reunion, F = Argentina, G = Australia, H = Japan

-                The carriage return start bit begins on 0 seconds and extends to 1 bit time.
-        
-        Notes on 468-DC and OMEGA receiver:
-        Send the clock a R or C and once per second a timestamp will appear. Send a R to get the satellite position once (GOES only).
-        Notes on the 468-DC receiver:
-        Since the old east/west satellite locations are only historical, you can't set your clock propagation delay settings correctly and still use automatic mode. The manual says to use a compromise when setting the switches. This results in significant errors. The solution; use fudge time1 and time2 to incorporate corrections. If your clock is set for 50 and it should be 58 for using the west and 46 for using the east, use the line
-        fudge 127.127.5.0 time1 +0.008 time2 -0.004
-        This corrects the 4 milliseconds advance and 8 milliseconds retard needed. The software will ask the clock which satellite it sees.
-        The PCL720 from PC Labs has an Intel 8253 look-alike, as well as a bunch of TTL input and output pins, all brought out to the back panel. If you wire a PPS signal (such as the TTL PPS coming out of a GOES or other Kinemetrics/Truetime clock) to the 8253's GATE0, and then also wire the 8253's OUT0 to the PCL720's INPUT3.BIT0, then we can read CTR0 to get the number of microseconds since the last PPS upward edge, mediated by reading OUT0 to find out if the counter has wrapped around (this happens if more than 65535us (65ms) elapses between the PPS event and our being called.)
-        Monitor Data
-        When enabled by the flag4 fudge flag, every received timecode is written as-is to the clockstats file.
-        Fudge Factors
-        
-            time1 time
-            
Specifies the time offset calibration factor, in seconds and fraction, to be used for the West satellite, with default 0.0.
-            
time2 time
-            
. Specifies the time offset calibration factor, in seconds and fraction, to be used for the East satellite, with default 0.0.
-            
stratum number
-            
Specifies the driver stratum, in decimal from 0 to 15, with default 0.
-            
refid string
-            
Specifies the driver reference identifier, an ASCII string from one to four characters, with default TRUE.
-            
flag1 0 | 1
-            
Silence the clock side of ntpd, just reading the clock without trying to write to it.
-            
flag2 0 | 1
-            
Generate a debug file /tmp/true%d.
-            
flag3 0 | 1
-            
Not used by this driver.
-            
flag4 0 | 1
-            
Not used by this driver.
-        
-        Additional Information
-        Reference Clock Drivers
-        
-        
-    
+	
+		TrueTime GPS/GOES/OMEGA Receivers
+		
+		Synopsis
+		Address: 127.127.5.u

+		Reference ID: GPS, OMEGA, GOES

+		Driver ID: TRUETIME

+		Serial Port: /dev/trueu; 9600 baud, 8-bits, no parity

+		Features: tty_clk
+		Description
+		This driver supports several models models of Kinemetrics/TrueTime timing receivers, including 468-DC MK III GOES Synchronized Clock, GPS- DC MK III and GPS/TM-TMD GPS Synchronized Clock, XL-DC (a 151-602-210, reported by the driver as a GPS/TM-TMD), GPS-800 TCU (an 805-957 with the RS232 Talker/Listener module), OM-DC OMEGA Synchronized Clock, and very likely others in the same model family that use the same timecode formats.
+		Most of this code is originally from refclock_wwvb.c with thanks. It has been so mangled that wwvb is not a recognizable ancestor.
+		Timcode format: ADDD:HH:MM:SSQCL A - control A (this is stripped before we see it) Q - Quality indication (see below) C - Carriage return L - Line feed Quality codes indicate possible error of
+		
+			468-DC GOES Receiver

+				GPS-TM/TMD Receiver
+			
? +/- 500 milliseconds # +/- 50 milliseconds

+				* +/- 5 milliseconds . +/- 1 millisecond

+				space less than 1 millisecond
+			
OM-DC OMEGA Receiver:
+			
> +/- 5 seconds

+				? +/- 500 milliseconds # +/- 50 milliseconds

+				* +/- 5 milliseconds . +/- 1 millisecond

+				A-H less than 1 millisecond. Character indicates which station is being received as follows

+				A = Norway, B = Liberia, C = Hawaii, D = North Dakota, E = La Reunion, F = Argentina, G = Australia, H = Japan

+				The carriage return start bit begins on 0 seconds and extends to 1 bit time.
+		
+		Notes on 468-DC and OMEGA receiver:
+		Send the clock a R or C and once per second a timestamp will appear. Send a R to get the satellite position once (GOES only).
+		Notes on the 468-DC receiver:
+		Since the old east/west satellite locations are only historical, you can't set your clock propagation delay settings correctly and still use automatic mode. The manual says to use a compromise when setting the switches. This results in significant errors. The solution; use fudge time1 and time2 to incorporate corrections. If your clock is set for 50 and it should be 58 for using the west and 46 for using the east, use the line
+		fudge 127.127.5.0 time1 +0.008 time2 -0.004
+		This corrects the 4 milliseconds advance and 8 milliseconds retard needed. The software will ask the clock which satellite it sees.
+		The PCL720 from PC Labs has an Intel 8253 look-alike, as well as a bunch of TTL input and output pins, all brought out to the back panel. If you wire a PPS signal (such as the TTL PPS coming out of a GOES or other Kinemetrics/Truetime clock) to the 8253's GATE0, and then also wire the 8253's OUT0 to the PCL720's INPUT3.BIT0, then we can read CTR0 to get the number of microseconds since the last PPS upward edge, mediated by reading OUT0 to find out if the counter has wrapped around (this happens if more than 65535us (65ms) elapses between the PPS event and our being called.)
+		Monitor Data
+		When enabled by the flag4 fudge flag, every received timecode is written as-is to the clockstats file.
+		Fudge Factors
+		
+			time1 time
+			
Specifies the time offset calibration factor, in seconds and fraction, to be used for the West satellite, with default 0.0.
+			
time2 time
+			
. Specifies the time offset calibration factor, in seconds and fraction, to be used for the East satellite, with default 0.0.
+			
stratum number
+			
Specifies the driver stratum, in decimal from 0 to 15, with default 0.
+			
refid string
+			
Specifies the driver reference identifier, an ASCII string from one to four characters, with default TRUE.
+			
flag1 0 | 1
+			
Silence the clock side of ntpd, just reading the clock without trying to write to it.
+			
flag2 0 | 1
+			
Generate a debug file /tmp/true%d.
+			
flag3 0 | 1
+			
Not used by this driver.
+			
flag4 0 | 1
+			
Not used by this driver.
+		
+		Additional Information
+		Reference Clock Drivers
+		
+		
+	
 
 
\ No newline at end of file
diff --git a/html/pic/fig_3_1.gif b/html/pic/fig_3_1.gif
index d0aafaccf..a280a8903 100644
Binary files a/html/pic/fig_3_1.gif and b/html/pic/fig_3_1.gif differ
diff --git a/html/warp.html b/html/warp.html
index 90bb68217..240c6caf2 100644
--- a/html/warp.html
+++ b/html/warp.html
@@ -9,7 +9,7 @@
 
 How NTP Works
 Last update:
-  14-Oct-2010  3:26
+  14-Oct-2010  16:45
   UTC
 Related Links
 
@@ -28,7 +28,8 @@
   
   Figure 1. NTP Daemon Processes and Algorithms
 
-The overall organization of the NTP daemon is shown in Figure 1. It is useful in this context to consider the daemon as both a client of upstream servers and as a server for downstream clients. It includes a pair of peer/poll processes for each reference clock or remote  server used as a synchronization source. The poll process sends NTP packets at intervals ranging from 8 s to 36 hr. The peer process receives NTP packets and  performs  the packet sanity tests    of the flash status word. Packets that fail one or more of these tests are summarily discarded. Otherwise, the peer process runs the on-wire protocol that uses four raw timestamps: the origin timestamp T₁ upon departure of the client request, the receive timestamp T₂ upon arrival at the server, the transmit timestamp T₃ upon departure of the server reply, and the destination timestamp T₄ upon arrival at the client. These timestamps, which are recorded by the rawstats option of the filegen command, are used to calculate the clock offset and roundtrip delay samples:
+The overall organization of the NTP daemon is shown in Figure 1. It is useful in this context to consider the daemon as both a client of upstream servers and as a server for downstream clients. It includes a pair of peer/poll processes for each reference clock or remote  server used as a synchronization source. Packets are exchanged between the client and server using the on-wire protocol described in  the white paper Analysis and Simulation of the NTP On-Wire Protocols. The protocol is resistant to lost, replayed or spoofed packets.
+ The poll process sends NTP packets at intervals ranging from 8 s to 36 hr. The peer process receives NTP packets and  performs  the packet sanity tests    of the flash status word. Packets that fail one or more of these tests are summarily discarded. Otherwise, the peer process runs the on-wire protocol that uses four raw timestamps: the origin timestamp T₁ upon departure of the client request, the receive timestamp T₂ upon arrival at the server, the transmit timestamp T₃ upon departure of the server reply, and the destination timestamp T₄ upon arrival at the client. These timestamps, which are recorded by the rawstats option of the filegen command, are used to calculate the clock offset and roundtrip delay samples:
 
   offset = [(T₂ - T₁) + (T₃ - T₄)] / 2

     delay = (T₄ - T₁) - (T₃ - T₂).

Code	Tag	Message	Description	Code	Tag	Message	Description
`0001`	`0004`	TEST3	`pkt_unsync`	protocol unsynchronized	server not synchronized
`0008`	`0010`	TEST5	`pkt_auth`	bad authentication	authentication failure
`0020`	TEST6	`pkt_stratum`	bad synch or stratum	invalid leap or stratum
`0040`	TEST7	`pkt_header`	bad header	header distance exceeded
`0080`	TEST8	`pkt_autokey`	bad autokey	Autokey sequence error
`0100`	TEST9	`pkt_crypto`	bad crypto	Autokey protocol error
`0200`	TEST10	`peer_stratum`	peer bad synch or stratum	invalid header or stratum
`0400`	TEST11	`peer_dist`	peer distance threshold exceeded	distance threshold exceeded
`0800`	TEST12	`peer_loop`	peer synchronization loop	synchronization loop
`1000`	TEST13	`peer_unreach`	peer unreachable or nonselectable	unreachable or nonselect