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: Unresolved
    • 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 GNSS module is capable of reporting both the GPS FIX state and the GNSS offset, which represents the offset between the GNSS module and the constellations. However, the current T-GM does not utilize the ubloxtool to probe the ublox module for reading the offset and GPS FIX. Instead, it can only read the GPS FIX information via GPSD. The reason for this is that the current implementation of the ubloxtool command-line interface takes 2 seconds to receive a response, and with every call, it increases CPU usage by threefold. Unless the ubloxtool request is optimized, the GPS offset will remain unavailable.
      Show
      The GNSS module is capable of reporting both the GPS FIX state and the GNSS offset, which represents the offset between the GNSS module and the constellations. However, the current T-GM does not utilize the ubloxtool to probe the ublox module for reading the offset and GPS FIX. Instead, it can only read the GPS FIX information via GPSD. The reason for this is that the current implementation of the ubloxtool command-line interface takes 2 seconds to receive a response, and with every call, it increases CPU usage by threefold. Unless the ubloxtool request is optimized, the GPS offset will remain unavailable.
    • 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: