You need to enable JavaScript to fully utilise this page.

RADclock configuration

The man pages contain all information (and are hopefully up to date), this page summarises the key elements of configuration to help you get started.

Selecting the timecounter/clocksource

Before using the RADclock, you need to select a counter corresponding to your needs. If your client is a laptop, has a multi-core CPU, supports CPU frequency stepping or power management, the Time Stamp Counter (TSC) should NOT be chosen. The HPET counter (if available) is usually a safe choice.


To list the available counters:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

To select the HPET counter:

echo "hpet" > /sys/devices/system/clocksource/clocksource0/current_clocksource


To list the available counters:

sysctl kern.timecounter.choice

To select the HPET counter:

sysctl kern.timecounter.hardware=HPET

First run

Using the startup script (see Installation), the first run of the RADclock will create a configuration file /etc/radclock.conf whose main options are discussed below.

Flow of synchronisation packets

The current version of the RADclock relies on a continuous stream of NTP packets exchanged with an NTP server in order to synchronise.

There are two ways of generating the flow of NTP packets used by the RADclock. On the one hand, you can keep your existing ntpd daemon running to synchronise your computer's system clock. In such a case, the RADclock can divert the NTP packets via LibPcap without interfering with ntpd. We called that piggybacking. On the other hand, you can stop the ntpd daemon and let the RADclock generate its own flow of NTP packets. Note that the RADclock will NOT adjust your system clock, but depending on your application this may be the right choice. There are pros and cons to both solutions, not detailed here, but the RFC1589 may be a place to start and satisfy your curiosity.

In any case, and for best performance for both ntpd and the RADclock you do not want two flows of NTP packets from your client to the same server (if you have a collection of high quality NTP servers nearby, it is a different story). So your system configuration should either be:

Configuring ntpd for the RADclock

ntpd performs much better if it is configured to communicate with:

This type of configuration also suits the RADclock. So if you choose to keep your ntpd daemon running it must be configured with something like (/etc/ntp.conf):

driftfile /etc/ntp/drift
server minpoll 4 maxpoll 4 prefer

This configuration for ntpd may raise questions regarding robustness. For example, "What if my only server dies?". Well this does not happen often. Also, again, ntpd will perform overall better while listening to a single server and losing packets than listening to many servers. Finally, the RADclock is extremely robust to network disruption and packet loss. So if your chosen server disappear for a while, it is not an issue.

RADclock Configuration Options

Here we highlight the key options you have to edit in the RADclock configuration file.

To obtain some verbose output from the RADclock daemon, set the verbose_level option to normal.

# Verbosity level of the radclock daemon.
verbose_level = normal

Synchronisation Client parameters

If you have an ntpd daemon running then set synchro_type=piggy, otherwise, synchro_type=ntp.

# Specify the type of underlying synchronisation used.
synchro_type = ntp 

The polling period option corresponds to the time between two NTP packets sent to the server. If you use the piggybacking option, this value should match the one given in the ntpd configuration file. Otherwise, this can be any value. The smaller the poll period, the better the synchronisation. As a rule of thumb, 16 seconds has been proven to be a good trade-off between accuracy and load induced on the server.

# The polling period specifies the time interval at which
# the script send NTP requests (value in seconds)
polling_period = 16 

To be sure that the RADclock capture the correct NTP packets on the network, please specify here the hostname or IP address of your client and the NTP server it synchronises to. Again this should match the configuration of ntpd if you use the piggybacking option. Also, keep in mind that the closer the server (in number of hops), the higher accuracy.

# Hostname or IP address (uses lookup name resolution).
# Automatic detection will be attempted if not specified.
hostname = 

# Time server answering the requests from this client.
# Can be a host name or an IP address (uses lookup name resolution).
time_server =

Synchronisation Server parameters

Time is served to 3rd party program via an IPC socket. The serve_data option has to be set to 1 for other programs to access the RADclock time information

# IPC server.
# Serves time to the kernel and other processes.
#   on : Stop service  - useful when replaying traces
#   off: Start service - makes the RADclock available to other programs
ipc_server = on

The RADclock can serve time to RADclock clients over the network using the NTP protocol. This is incompatible with the piggybacking mode. This is still an experimental feature.

# NTP server.
# Serves time to radclock clients over the network.
#   on : no server running
#   off: runs a NTP server for remote clients
ntp_server = off

In case you have to restart the RADclock, the last run has written in its log file, the last good value of your CPU period estimate. For a quick restart, you can put this value in the configuration file and get accurate synchronisatino faster.

# For a quick start, the initial value of the period of the counter 
# (in seconds). 
init_period_estimate = 1.675332185e-09

Network level parameters

Input / Output parameters

If your client has multiple network interfaces, the RADclock will try to resolve the one corresponding to the IP address or hostname given above. This may fail however, and depends on your network/client set up. Use the network_interface option to specify which network card is sending and receiving NTP packets.

# Network device.
# Specify a different interface (xl0, eth0, ...)
# If none, the RADClock will lookup for a default one.
#network_device = xl0

The RADclock has the ability to replay NTP packets streams, and recompute all its timestamps. This is a priceless features for network measurements of all kind in case something go wrong (you can then re-create all your timestamps in post-processing). Specify a file to which store the NTP packets captured in PCAP format.

# RAW output file.
sync_output_pcap = /capture/radclock_packets.pcap