OCP-TAP Servo Workstream

Meeting

June 13, 2022

Agenda

• Proposed scope and actions

​

Requirements Gathering

• Problem Formulation
• Alon to draft initial text
• Understanding the network & system/hardware
• Data Center PTP profile is one source of requirements
• Requirements from other workstreams
• Reach out to other workstream
• Application-level (customer) requirements
• i.e. can we have an algorithm/system that is more adaptive
• Theory of operations?
• Create “wishlist” brainstorm on the Wiki
• Invite experts to present experience / problems to the workstream
• Example: open source solutions such as linuxptp
• Define where in the system the Servo can go

Problem Formulation - 1

• A time servo attempts to maintain frequency and phase alignment between a time reference and a servo-controlled time source using a closed-loop negative feedback control loop
• In addition, a time servo may need to support
• Fast start-up algorithm for correction of large errors
• Monitoring of the synchronization quality including feedback to users
• Holdover (open-loop) when reference time is not available or is not usable
• Switching to a different time reference without any phase jumps or large changes in frequency
• Potentially support having the algorithm selection and parameterization automatically and dynamically driven by the system’s performance parameters (listed above)
• Potentially providing feedback to the system such as the required SYNC message rate to achieve the desired performance
• A time servo’s performance is limited by
• Stability of the local oscillator
• Rate and accuracy of the reference inputs
• Range and resolution of control outputs
• Delays from sensing to the loop and from loop to effect
• Algorithm and parameters

Problem Formulation - 2

• In a datacenter architecture there are many time servos. Examples include:
• Within the miniature atomic clock (typically implemented by vendor)
• Within GNSS acquisition system (typically implemented by vendor)
• Synchronize Time Appliance PHC (i.e. in NIC) with the time reference (i.e. GNSS) input
• Synchronize BC to BC’s follower PTP incoming clock
• Synchronize OC’s system clock to the PTP incoming clock
• Work with the Servo Workstream includes
• Understanding the data center servo requirements and performance of components used in said datacenter applications
• These are defined by the profile, hardware used, application needs, and other inputs
• Cooperation / coordination with other workflows to understand requirements and dependencies
• Select, define, implement, and/or test servo algorithms and solutions that meets the data center requirements for the different types/locations of servos in the system

​

Proposed initial scope and actions

• Start by focusing on the Servo synchronizing the Time Appliance PHC (i.e. in NIC) with the time reference (i.e. GNSS) input
• This is better understood / constrained both in the Data Center Profile as well as the analysis by the oscillators workstream
• Experiments/changes limited to ptp4u & ts2phc
• Document requirements
• Documents algorithm & behavior of existing implementation
• Research, discuss, compare, and simulate potential algorithms & parameters.
• This includes algorithms both for the core servo as well as for characterizing the synchronization accuracy, stability, and performance

​

Ptp4u analysis

• This is purely a protocol implementation
• No actual servo in ptp4u
• GNSS / PPS input to frequency & timestamp conversion done elsewhere
• In the OCP timingcard, this is done in the FPGA in the AdjustableClock IP which includes a PI loop
• In other implementations this can be done in HW, FPGA, ASIC, or SW
• Sync between time card and NIC PHC done elsewhere
• phc2sys/ts2phc (or equivalent) to sync time card and NIC
• No PTM support

ts2phc

• Servo is used to synchronize PHC “sinks” to the timestamp source data
• Uses default PI servo in linuxptp
• Linuxptp shares the servo code (between ptp4l, phc2sys and ts2phc)
• Algorithms are PI, Adaptive Linear Regression, NTP SHM, and Null frequency adjust algorithms
• No option for externally defined servo today
• Parameters are configurable at startup
• Ts2phc does not expose any servo configuration
• Default values are always used

phc2sys

• Servo is used to synchronize clock “sink” to the source clock
• Exposes servo configuration allowing configuration of servo type and parameters
• Parameters are configured at startup only

​

Issues

• No defined requirements
• Where is the Servo? On the timecard, NIC, or system?
• What stability is needed?
• Dependent on local oscillator, timestamping, 1pps quality, etc.
• This is typically proprietary limiting available public standards and test specifications
• How do we bound the requirements?

Discussions on Proposed initial scope

• Start by defining all the Servos in the system
• What interfaces are defined?
• Are requirements defined?
• Are there standards
• Proposal: Focus on the NIC side (either with PTP input or even integrated 1PPS input)
• This has defined interfaces
• How do we generate PTP (and optionally Sync-E clocks)?
• How do we get the time accurately into the application?
• Document requirements
• Later documents algorithm & behavior of existing implementation
• Finally research, discuss, compare, and simulate potential algorithms & parameters.
• This includes algorithms both for the core servo as well as for characterizing the synchronization accuracy, stability, and performance

​