Leitch Csd 5300 Manual

admin


Configuring NTP server and client on Solaris 10 and Solaris 11

  1. The LEITCH CSD-3901 Master Clock System Driver allows programming of time code user bits. This facility can be used to include a specific time offset in the time code. The operating mode of one or more ADCs in a system can then be set to read this offset. A typical application is the display of GMT in addition to local time.
  2. Type 13 Leitch CSD 5300 Master Clock Controller (ATOMLEITCH) Type 14 EES M201 MSF Receiver (MSFEES) Type 15. TrueTime generic receivers Type 16 Bancomm GPS/IRIG Receiver (GPSBANCOMM) Type 17 Datum Precision Time System (GPSDATUM) Type 18 NIST Modem Time Service (ACTSNIST) Type 19 Heath WWV/WWVH Receiver (WWVHEATH).

This manual provides commissioning, verification, and validation information for the Rosemount 5300 Series Radar Transmitters. This manual is intended to be used with the Rosemount 5300 Series Reference Manual (document number -4530). 1.2 Tools The following tools and documents are recomm ended to use during the installation. # 13 leitch ATOM Leitch CSD 5300 Master Clock Controller # 15. TrueTime GPS/TM-TMD Receiver # 17 datum DATM Datum Precision Time System # 18 acts ACTS NIST Automated Computer Time Service # 19 heath WWV Heath WWV/WWVH Receiver # 20 nmea GPS Generic NMEA GPS Receiver # 22 atom PPS PPS Clock Discipline.

One of the task which often performed during the setup of a machine is the setup of the NTP daemon.
NTP is one of the oldest internet protocol still in use and it allows the synchronization of computer clocks distributing UTC (Coordinated Universal Time) over the network. NTP design is focused on compensating the variable latency of the network.
A machine may be an NTP client or an NTP server. Roughly, an NTP client it's a machine that uses the NTP protocol to synchronize its clock and an NTP server it's a machine that provides NTP client the information needed to synchronize their clocks. An NTP server often uses other NTP servers to keep its own clock in sync.
This blog post has been slightly updated to accomodate some minor modifications to support Solaris 11.

NTP on Solaris 10 and Solaris 11

Solaris 10 introduced the SMF framework (to simplify and enhance the service management tasks in Solaris environments) and the NTP service is now managed by SMF. Solaris ships with an NTP daemon,

Leitch Csd-5300 Manual

ntpd, configured via SMF (svc:/network/ntp:default) and a bunch of sample ntp.confManual files to quickly configure a machine as a client or as a server.
# svcs ntp
STATE STIME FMRI
online 0:43:33 svc:/network/ntp:default
Solaris 11 only ships with NTP v. 4, while your Solaris 10 installation may ship with both. In this case, the NTP v. 4 service is identified by the name ntp4. I suggest you always use the latest version. As we'll see in the following sections, NTP v. 4 offers you more flexibility when configuring your server.

Configuring a client

If your machine is just a client, you can just pick the /etc/inet/ntp.client and copy it to/etc/inet/ntp.conf. The default client configuration it's just a one-liner:

multicastclient 224.0.0.1
This configuration, as explained in the same file, it's a passive configuration for a host that just listens for NTP server putting packets on the NTP multicast network, 224.0.0.1.
Obviously, if your machine it's in a LAN without an NTP server, you're probably never going to receive such a packet, and you should use some public NTP server instead.

Using a server from a pool

I personally recommend using random servers from an NTP pool such as pool.ntp.org. In the official website of the NTP Pool Project you can find instruction about using the pool or picking up some server from the list they maintain. Pools maintained by the NTP Pool Project are organized in geographical hierarchy so that, for example, you can use server from a continent-level pool or, where available, from a country-level pool. The recipe is always the same: the nearer, the quicker and the better. In the case of the NTP protocol, moreover, the nearerthe server you use, the more accurate the synchronization.
In my case, I'm using the European pool europe.pool.ntp.org and my configuration file contains:
server 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server 3.europe.pool.ntp.org
Normally NTP requires a poll period to elapse before starting synchronizing your clock. If you want NTP to start immediately, which you most probably will if you're configuring a desktop environment, you can take advantage of iburst keyword, introduced in NTP v. 4: it instructs NTP to start the synchronization almost right away.
server 0.europe.pool.ntp.org iburst
server 1.europe.pool.ntp.org iburst
server 2.europe.pool.ntp.org iburst
server 3.europe.pool.ntp.org iburst
Another option, instead of manually maintaining multiple server lines, is using the pool keyword. The difference between the two is subtle and may be very convenient to use: server just tells NTP to use thefirst IP address returned by the DNS lookup, while pool tells NTP to use them all.
Beware that iburst and pool are NFS v. 4 specific keywords: make sure you're configuring NTP implementation corresponding to the syntax you're using.

Setting up the drift file

The only thing left to set up it's just the drift file location, which in my case it's:
driftfile /var/ntp/ntp.drift

Starting the service

Once your ntp.conf is set up, you can start (or restart) the ntp service:
# svcadm restart ntp
# svcs ntp
STATE STIME FMRI
online 0:43:33 svc:/network/ntp:default
In case you're wondering: there's no need to run the ntpdate command. The SMF scripts of the NTP service takes care of all (in this case, during the execution of the start method).

Querying the service

Once the service is running, you can check which server you're using with ntpq:
$ ntpq -p
remote refid st t when poll reach delay offset jitter
+dns2.vnet.sk 195.113.144.201 2 u 122 128 377 90.907 5.002 0.678
*ptbtime1.ptb.de .PTB. 1 u 26 128 377 91.754 2.971 2.715
-ntppub.le.ac.uk 158.43.192.66 2 u 105 128 377 76.720 10.182 3.701
+mx-dub.bofh.so 193.1.31.66 2 u 84 128 377 70.090 8.049 0.549

You'll get a similar output. After a while, your query will output similar results. The server prefixed with an asterisk is the server you're synchronizing with. If you don't get an asterisk after a while, probably no NTP server is reachable, which is probably due to a firewall which is blocking UDP port 123.
The difference between your clock and the data provided by NTP servers can be examined by catting the drift file:
# cat /var/ntp/ntp.drift-50.645

Setting up an NTP server

Now that you have an NTP client running, you'll probably want to setup all of your machines. If you're in a LAN, you can setup an internal NTP server which will provide data to other clients on your LAN. As before, you can take inspiration from the server configuration file shipped with Solaris 10 or Solaris 11,/etc/inet/ntp.server. After setting up the drift file and the clients you're going to use, you can examine the other options and fine-tune them at your taste. Let's give a quick look at it.
server 127.127.XType.0
This line pretty much resembles the server statement we described in the previous sections but it's fundamentally different. The argument of the server keyword, which resembles an IP address, give NTP information about the kind of device used to provide the (supposedly) accurate time to the NTP server.
The server type and the XType value must be substituted with the correct value from the provided table (and reported in the configuration file shipped with Solaris as well):

# XType Device RefID Description

Leitch Csd-5300 Manual

5300
# -------------------------------------------------------
# 1 local LCL Undisciplined Local Clock
# 2 trak GPS TRAK 8820 GPS ReceiverCsd-5300
# 3 pst WWV PSTI/Traconex WWV/WWVH Receiver
# 4 wwvb WWVB Spectracom WWVB Receiver
# 5 true TRUE TrueTime GPS/GOES Receivers
# 6 irig IRIG IRIG Audio Decoder
# 7 chu CHU Scratchbuilt CHU ReceiverLeitch csd-5300 user manual
# 8 parse ---- Generic Reference Clock Driver
# 9 mx4200 GPS Magnavox MX4200 GPS Receiver
# 10 as2201 GPS Austron 2201A GPS Receiver
# 11 arbiter GPS Arbiter 1088A/B GPS Receiver
# 12 tpro IRIG KSI/Odetics TPRO/S IRIG Interface
# 13 leitch ATOM Leitch CSD 5300 Master Clock Controller
# 15 * * TrueTime GPS/TM-TMD ReceiverLeitch Csd 5300 Manual
# 17 datum DATM Datum Precision Time System
# 18 acts ACTS NIST Automated Computer Time Service
# 19 heath WWV Heath WWV/WWVH Receiver
# 20 nmea GPS Generic NMEA GPS Receiver
# 22 atom PPS PPS Clock Discipline
# 23 ptb TPTB PTB Automated Computer Time Service
# 24 usno USNO USNO Modem Time Service
# 25 * * TrueTime generic receivers
# 26 hpgps GPS Hewlett Packard 58503A GPS Receiver
# 27 arc MSFa Arcron MSF Receiver
In my case, it's just a (very) plain 1: an undiscilplined local clock.
broadcast 224.0.1.1 ttl 4
This line is the server equivalent of the multicast line seen in the default client configuration: it tells the NTP server to broadcast on the NTP multicast network.

Further readings

Complete documentation about

Leitch Csd-5300 User Manual

ntp.conf syntax can be found on the xntpd man page:
# man xntpd