Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
X xlte
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Kirill Smelkov
  • xlte
  • Merge requests
  • !3

Closed
Created Jan 06, 2023 by Xavier Thompson@xavier_thompson
  • Report abuse
Report abuse

WIP: amari.xlog: Approximate utc timestamp

  • Overview 20
  • Commits 1
  • Changes 1

Older versions of lteenb do not implement .utc field in remote API reponses, only .time which is relative to the start of the process. For such versions, inject an approximation of .utc into each logged message.

Without this the KPI computation from enb.xlog fails because .utc is missing. Also, it is generally useful to know when each message was logged, e.g. to implement promises on lteenb statistics using enb.xlog.

Approximation method

We take utc0 = time.now() as an approximation of the .utc time when receiving the first message after (re)connecting, and then for each subsequent message we compute utc = utc0 - time0 + time.

Quick empirical comparisons with the actual .utc field seem to show this is more precise than finding out the creation time of lteenb process and computing utc = utc_start + time, by one order of magnitude: the first seems precise to 0.1s, while the second may be off by up to 1s.

Both methods preserve the relative time interval between each message, as given by the .time field.

Correlation with enb.log

Currently, only the E-RAB Accessibility KPI is implemented, and it relies only on enb.xlog. So the approximation doesn't matter since the relative time intervals between messages are preserved.

However, other KPIs will require correlating events between enb.log and enb.xlog, for which end the .utc field would be used. It is hoped that the approximation might be good enough to produce reasonable results for such KPIs.

Assignee
Assign to
Reviewer
Request review from
None
Milestone
None
Assign milestone
Time tracking
Source branch: feat/approx_utc
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7