Uploaded image for project: 'OpenShift Bugs'
  1. OpenShift Bugs
  2. OCPBUGS-17422

GNSS Offset between UBlox and constellations takes more than 1CPU

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done-Errata
    • Icon: Major Major
    • 4.16.0
    • 4.14.0, 4.14.z
    • Networking / ptp
    • None
    • No
    • CNF RAN Sprint 241, CNF RAN Sprint 242, CNF RAN Sprint 243, CNF RAN Sprint 244, CNF RAN Sprint 245, CNF RAN Sprint 247, CNF RAN Sprint 248, CNF RAN Sprint 249, CNF RAN Sprint 250
    • 9
    • False
    • Hide

      None

      Show
      None
    • Hide
      * The global navigation satellite system (GNSS) module is capable of reporting both the GPS `fix` position and the GNSS `offset` position, which represents the offset between the GNSS module and the constellations. However, the previous T-GM did not utilize the `ubloxtool` CLI tool to probe the `ublox` module for reading `offset` and `fix` positions. Instead, it could only read the GPS `fix` information via GPSD. The reason for this was that the previous implementation of the `ubloxtool` CLI tool took two seconds to receive a response, and with every call it increased CPU usage by threefold. With this update, the `ubloxtool` request is now optimized, and the GPS `offset` position is now available. (link:https://issues.redhat.com/browse/OCPBUGS-17422[*OCPBUGS-17422*])
      Show
      * The global navigation satellite system (GNSS) module is capable of reporting both the GPS `fix` position and the GNSS `offset` position, which represents the offset between the GNSS module and the constellations. However, the previous T-GM did not utilize the `ubloxtool` CLI tool to probe the `ublox` module for reading `offset` and `fix` positions. Instead, it could only read the GPS `fix` information via GPSD. The reason for this was that the previous implementation of the `ubloxtool` CLI tool took two seconds to receive a response, and with every call it increased CPU usage by threefold. With this update, the `ubloxtool` request is now optimized, and the GPS `offset` position is now available. (link: https://issues.redhat.com/browse/OCPBUGS-17422 [* OCPBUGS-17422 *])
    • Bug Fix
    • Done
    • Hide
      2/29: PR under review
      2/22: development and testing in progress for updated changes - forecast next week for PR
      2/8: PR under review
      1/18: PR pushed, need Aneesh to review
      12/7: Dev work started
      11/23: Development will continue after 2 card QE/Bug fixing
      11/17: Development will continue after 2 card QE/Bug fixing
      11/13: Have a solution without requiring any fix, going to implement new method to get the ublox offset and measure cpu usage before reporting back on the bug .
      11/06 : waiting on rhel fix
      10/30 : waiting on rhel fix
      10/2: opened a kernel bug to improve usage
      9/28: open a bug to report 150milicore and 2 secs turn around time
      9:25: verification pending , waiting selinux fix for gpsd backported to rhel9.2
      9:21: verification pending , waiting selinux fix for gpsd backported to rhel9.2
      9/14: tested with new changes , trhe CPU usage is now reduced to 150 mc. Need more improvement to be done in ublox/ gpsd .
      9/12: gpsd changes are now available, code will be updated to read gps offset and measure CPU usage, Will be done this week.
      9/2: moved to next week -
      8/28: ubi9 with gpsd fix is now available in dev release, will verify this as soon as ubi9 + gpsd ifx is available in prod
      8/21: unlox/gpsd fix is now available. This week there will be a Linuxptpdaemon container built (ubi9+ gpsd fix) with the new fix and ready to verify ublox offset & CPU usage fix.
      8/14: we need a build which includes the ublx fix. Not urgent since this call has been removed in the main code stream.
      Show
      2/29: PR under review 2/22: development and testing in progress for updated changes - forecast next week for PR 2/8: PR under review 1/18: PR pushed, need Aneesh to review 12/7: Dev work started 11/23: Development will continue after 2 card QE/Bug fixing 11/17: Development will continue after 2 card QE/Bug fixing 11/13: Have a solution without requiring any fix, going to implement new method to get the ublox offset and measure cpu usage before reporting back on the bug . 11/06 : waiting on rhel fix 10/30 : waiting on rhel fix 10/2: opened a kernel bug to improve usage 9/28: open a bug to report 150milicore and 2 secs turn around time 9:25: verification pending , waiting selinux fix for gpsd backported to rhel9.2 9:21: verification pending , waiting selinux fix for gpsd backported to rhel9.2 9/14: tested with new changes , trhe CPU usage is now reduced to 150 mc. Need more improvement to be done in ublox/ gpsd . 9/12: gpsd changes are now available, code will be updated to read gps offset and measure CPU usage, Will be done this week. 9/2: moved to next week - 8/28: ubi9 with gpsd fix is now available in dev release, will verify this as soon as ubi9 + gpsd ifx is available in prod 8/21: unlox/gpsd fix is now available. This week there will be a Linuxptpdaemon container built (ubi9+ gpsd fix) with the new fix and ready to verify ublox offset & CPU usage fix. 8/14: we need a build which includes the ublx fix. Not urgent since this call has been removed in the main code stream.

      Description of problem:

      GNSS offset is required  along wth DPLL and ts2phc offsets to report the GM state as Locked . Current implmentation of reading GNSS offset via ublox tool client call takes more than 1CPU .In fact any call via ublox tool takes more than 1CPU. OCP 4.14 has now dropped any calls to ublox and uses direct GSPD calls to read the gps fix status. This only solves one problem of getting GPS status without ublox call  , But offset reading still needs Ublox cli execution via deaemon, hence the  reporting of offset is not implmented in 4.14 for now.

      Version-Release number of selected component (if applicable):

       

      How reproducible:

       

      Steps to Reproduce:

      1.
2.
3.

      Actual results:

       

      Expected results:

       

      Additional info:

       

              josricha@redhat.com Joseph Richard
              aputtur@redhat.com Aneesh Puttur
              Hen Shay Hassid Hen Shay Hassid
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: