Configure PTP on Silicom TimeSync (STS) Server Adapter

The Silicom TimeSync Server Adapter (STS) provides local time sync support via a local GNSS module which is based on Intel E810 chipset.

For additional information, see https://www.silicom-usa.com/pr/server-adapters/networking-adapters/10-gigabit-ethernet-networking-adapters/p410g8ts81-timesync-server-adapter/

The Silicom STS card operates in two modes: regular NIC mode and timing mode.

Packaged as a system application, the sts-silicom application provides the ability to configure the STS cards in timing mode and specify time sync parameters using helm-overrides.

About this task

On multi-node systems, a homogeneous deployment of the Silicom TimeSync (STS) cards is necessary since it’s not possible to specify different configurations for different nodes.

Limitations

  • Silicom and Intel based Time Sync NICs may not be deployed on the same system due to conflicting time sync services and operations.

    PTP configuration for Silicom TimeSync (STS) cards is handled separately from StarlingX host PTP configuration and may result in configuration conflicts if both are used at the same time.

    The sts-silicom application provides a dedicated phc2sys instance which synchronizes the local system clock to the Silicom TimeSync (STS) card. Users should ensure that phc2sys is not configured via StarlingX PTP Host Configuration when the sts-silicom application is in use.

    Additionally, if StarlingX PTP Host Configuration is being used in parallel for non-STS NICs, users should ensure that all ptp4l instances do not use conflicting domainNumber values.

  • When the Silicom TimeSync (STS) card is configured in timing mode using the sts-silicom application, the card goes through an initialization process on application apply and server reboots. The ports will bounce up and down several times during the initialization process, causing network traffic disruption. Therefore, configuring the platform networks on the Silicom TimeSync (STS) card is not supported since it will cause platform instability.

Procedure

The following example uses a Grand Master deployment on port enp81s0f3 with twoStep mode enabled:

  1. Install the application.

    ~(keystone_admin)]$ system application-upload /usr/local/share/applications/helm/sts-silicom-<n.n-nn>.tgz

  2. Create the configuration file and apply it.

    $ cat << EOF > sts_override.yaml
Spec:
  profileID: 2
  ports:
  - ethName: enp81s0f3
    ql: 4
    ethPort: 4
  masterPortMask_GM: 0x8
  syncePortMask_GM: 0x8
  twoStep: 1
EOF

~(keystone_admin)]$ system helm-override-update sts-silicom sts-silicom sts-silicom --values sts_override.yaml

~(keystone_admin)]$ system application-apply sts-silicom

  3. Check if the application is applied.

    ~(keystone_admin)]$ system application-show sts-silicom

Postrequisites

To update the application, remove and re-apply it with the new configuration.

  1. Remove the application.

~(keystone_admin)]$ system application-remove sts-silicom

  1. Edit sts_override.yaml.

  2. Apply the new configuration.

    ~(keystone_admin)]$ system helm-override-update sts-silicom sts-silicom sts-silicom --values sts_override.yaml
~(keystone_admin)]$ system application-apply sts-silicom

For more details on the configuration parameters, please consult the following Silicom documentation:

https://github.com/silicom-ltd/STS_HelmCharts

From https://silicom.ftptoday.com, under /STS/STS_Docs/ (credentials required):

  • STS_Products_Line_Quick_Start_Guide_v1.60.pdf

  • Linux_TSync_Prog_Guide_V2.4.pdf