White Rabbit, BuTiS, Clocks and Time

Introduction

Two systems exist for distribution of time stamps and clocks:
  1. The General Machine Timing System provides the following.
    1. A distributed 125 MHz clock via the Ethernet carrier of White Rabbit, see ingredients of White Rabbit.
    2. Timing Receivers also synthesize the 100kHz T0 and 200MHz c2 clocks of BuTiS (at reduced quality compared to BuTiS).
    3. Time stamps in TAI and UTC format are available at the timing receivers
    4. Time stamps and clock signals will have an accuracy in the low nanosecond range and a jitter in the picosecond range.
    5. Timing receiver boards are available in several form factors (PCIe, PMC, AMC and other) and of moderate price.
  2. The Bunch Timing System BuTiS provides the following.
    1. Clock trains (T0: 100kHz ident pulse, C2: 200 MHz sine) that are phase locked over the whole campus.
    2. BuTiS does not provide time stamps.
    3. The main focus of BuTiS is to provide reference clocks with low phase noise for rf-systems. An accuracy of about 100 picoseconds per kilometer and a jitter in the low femtosecond range is achieved.
    4. BuTiS hardware is available but a complete BuTiS receiver station is significantly more expensive than timing receivers of the GMT.

BuTiS

For high-precision synchronization beyond the parameters of the GMT (e.g. distributed rf- and kicker-control, bunch-to-bucket transfers, time-of-flight measurements) a Bunch Timing System (BuTiS) will distribute high precision clock trains (100 kHz ident pulse, 10 MHz sine). A propagation delay compensation is achieved by the use of a local reference synthesizer whose internal reference oscillator is phase locked to the distributed 10 MHz sine. A phase-locked 200 MHz clock is generated inside as well as the delayed ident pulse. The phase of the 200 MHz sine-wave clock is precisely adjustable in 1 degree steps (approx 14 picoseconds). Adjustments can be done locally or via Ethernet data connection. The phase shift data is derived from the propagation delay measurement system residing at the BuTiS center. An accuracy of about 100 picosends per kilometer and a jitter in the low femtosecond range is achieved.

timeSystem_butisLink.JPG
Figure: An overview on BuTiS and the GMT. A GPSDO serves as reference clock for BuTiS and the GMT.

A combination of a GPS Disciplined Oscillator (GPSDO) receiver and dedicated reference synthesizers is used to create a 10 MHz S1 sine. The S1 signal has a perfect long-term stability combined with a relative short-term (seconds) stability of about 10e-12. In addition, a 100 kHz ident pulse P0 is produced. Both signals S1 and P0 are sent to optical receivers (DWDM) over long distances. The bi-directional optical link allows measuring the link delays precisely. At the BuTiS center, correction data are calculated for each optical link and distributed via an Ethernet network (grey arrows) to so called local reference synthesizers (Ref. Synth.). Short copper links are used to transmit local clocks LP0 and LS1 from the optical receiver the reference synthesizer. At the reference synthesizer, a delay corrected C2 200 MHz sine and T0 100 kHz ident clocks are generated. Both clocks do not only have the same quality as the clocks provided at the BuTiS center but their phase is moreover locked and adjustable relative to the master clock at the BuTiS center. For more information on the reference synthesizer, please have a look here.

More information on BuTiS is given here.

BuTiS and GMT Clock Alignment

The clock master shown in the figure above is basically a White Rabbit switch. As reference clock input, it uses the physically same GPSDO as BuTiS.

controlSystemClocksWithoutSCUBackplane.jpg
Figure: Alignment of BuTiS and White Rabbit clocks.

The figure above shows the alignment of BuTiS and White Rabbit clocks. The rising edges of the White Rabbit generated PPS pulse, 10 MHz clock and 125 MHz clock are aligned. All FAIR Timing Receivers (FTRN) are able to generate BuTiS-like clocks such as T0' and c2' (not shown). By appropriate adjustments in the GPSDO as well as the BuTiS center, the rising edges of the BuTiS T0 and FTRN T0' clocks are are aligned with a skew better than 1 ns. This allows for an unambiguous identification of individual BuTiS c2 clock cycles.

GMT: Time, White Rabbit Based Clocks and Timestamps

Clocks

The generic clock of the timing system is the 125 MHz system clock driven by White Rabbit. The following gives an overview on clocks that could be connected to output pins.
  • Defined (almost) by configuration
    • 125 MHz clock
    • PPS pulse
    • clocks with a period >= 16 ns (8ns 'high', 8ns 'low')
  • Defined by synthesis, availability not guaranteed
    • either using 1GHz transceivers or specific FPGA clock domain
    • clocks with a period >= 2 ns (1ns 'high', 1ns 'low')
    • example: BuTiS 200 MHz clock
  • Special case, defined by synthesis, availability unlikely
    • other clocks
Important: A timing receiver can only generate clocks, that have a defined relationship to the White Rabbit clock.

Time

The definition of one second is based on an weighted average of many atomic clocks worldwide, see here. With TAI, a second is based on the SI second, one minute always equals of exactly 60 seconds and so on. Time is increasing strictly monotonically. There are no jumps, summer saving time, leap seconds or similar concepts. TAI has a different nature than UTC.

The General Machine Timing is based on White Rabbit PTP, White Rabbit is an extension of PTP. As PTP is based on TAI (Temps Atomique International). Thus, the time of the General Machine Timing is based on TAI.
  • Timescale
    • 'Timescale' describes how time advances ('how long is a second', aspects like 'continuity')
    • White Rabbit uses timescale PTP, which is continuous
    • the unit of measure of time is the SI second which is traceable to the international standards laboratories maintaining clocks that form the basis for the International Atomic Time (TAI)
    • sometimes 'timescale' suggests an 'epoch'
  • Epoch
    • 'Epoch' is the origin of the timescale (when your counters start with '0')
    • White Rabbit uses the PTP epoch
    • the PTP epoch is 1 January 1970 00:00:00 TAI, which is 31 December 1969 23:59:51.999918 UTC
    • (remark: UNIX epoch is 1 January 1970 00:00:00 UTC. This is an issue, as the current form of UTC was defined only in 1972. See here)
  • UTC Offset
    • when the epoch is PTP, it is possible to calculate UTC time using the value of the property 'utcOffset'
    • utcOffset = TAI ─ UTC
    • 'utcOffset' is published by the PTP grandmaster clock via the PTP announce messages
    • White Rabbit supports 'utcOffset' starting with WRS v5.1 and WRPC v4.2
  • GSI specific
    • timestamps: the unit of timestamps is nanoseconds and timestamps can be obtained from a couple of Wishbone devices such as the ECA unit
    • UTC conversion: At the time of this writing (August 2019) the timing API saftlib provides a 'time' data type, which provides time in TAI and/or UTC format depending on the users needs.

TAI = GPS + 19s; GPS = UTC + 18s (@2020); TAI = UTC + 37s @ 2020

Time @ GSI

  • Internal
    • Timescale: The General Machine Timing system is strictly coupled to the BuTiS system. 200 million clock cycles of the c2 clock equal one second. Both systems are coupled to the physical same reference clock. With respect to the absolute "true" TAI timescale, the uncertainty of timestamps is supposed to be below one microsecond. The unit of timestamps is nanoseconds and timestamps can be obtained from a couple of Wishbone devices such as the ECA unit.
    • Epoch: The White Rabbit network uses PTP epoch 1 January 1970 00:00:00 (TAI). At the time of this writing (August 2019) the use of a different epoch is not supported by the White Rabbit switches (announced for WRS 5.1) and not supported by the White Rabbit core (announced for WRC 4.2).
  • Public Interface
    • saftlib is the interface of the General Machine Timing system to the users
    • starting with saftlib 2.0 (rolled out with timing release enigma) saftlib no longer provides PTP timestamps as 64bit numbers in units of nanoseconds; instead, a dedicated 'Time' data type has been introduced
    • from now on, users should only use the new methods with the new 'Time' data type
    • the old methods with timestamps as 64bit numbers are deprecated and should no longer be used
    • see here

-- DietrichBeck - 10 February 2020
Topic revision: r29 - 19 Nov 2020, DietrichBeck
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback