Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-7894

Support for GNSS (GPS) as the primary time source and NTP as the secondary fallback.

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Unresolved
    • Icon: Major Major
    • None
    • openshift-4.20
    • None
    • None
    • Product / Portfolio Work
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None

      1. Proposed title of this feature request

      • Support for GNSS (GPS) as the primary time source and NTP as the secondary fallback.

      2. What is the nature and description of the request?

      • The Vi operator would like to use GNSS (GPS) as the primary time source and NTP as the secondary to achieve stable time synchronization.
        GNSS (GPS) as the primary source and NTP as the secondary.
        Samsung envisions the following behavior: #
        • On a single node, both linuxptp for GNSS and chrony for NTP are activated simultaneously.
          • linuxptp is responsible for synchronizing the system clock.
          • chrony is running but does not adjust the system clock.
        • When GNSS fails, the sync status transitions to HOLDOVER, and after the defined holdover time, it transitions to FREERUN.
        • Upon entering FREERUN, linuxptp should stop synchronizing the system clock (e.g., phc2sys is stopped), and if NTP is healthy, chrony is allowed to take over and synchronize the system clock.
        • When chrony takes over, it must gradually adjust the system clock to avoid sudden jumps — e.g., a correction rate limited to 10 nanoseconds per second.
          • Please let us know if such adjustment rate control is possible with chrony, and if so, how to configure it.
        • If GNSS recovers and becomes stable again during synchronization via NTP, the process should switch back in reverse:
          • chrony must stop synchronizing the system clock, and linuxptp (phc2sys) resumes control of the system clock synchronization.
      • https://docs.google.com/presentation/d/12JmRlmy3MVzYXzYvg3C52WiOFTADXEzwNX9KHkv6BX0/edit?slide=id.g36b1ec8a0db_1_186#slide=id.g36b1ec8a0db_1_186

      3. Why does the customer need this? (List the business requirements here)

      • The customer requires high-precision time synchronization for telecom workloads. GNSS (GPS) provides the primary timing source with the required accuracy, but in the event of GNSS failure, fallback to NTP is needed to maintain basic time continuity and avoid service disruptions. This dual-source configuration (GNSS primary, NTP secondary) is essential for maintaining system stability and resilience in production environments.

      4. List any affected packages or components.

      • chronyd (for NTP-based synchronization as fallback)
      • linuxptp (for GNSS/PTP synchronization)
      • phc2sys (for system clock adjustments from PHC)
      • Node time synchronization services in OpenShift or RHEL.
      • Event management components if used with O-RAN interface logic

       

       

              rolove Robert Love
              rhn-support-tdeokar Trushna Deokar
              None
              Votes:
              1 Vote for this issue
              Watchers:
              14 Start watching this issue

                Created:
                Updated:
                None
                None