Project

General

Profile

Bug #2339

osmo-bts-trx uses non-monotonic system clock for frame number timer

Added by laforge over 1 year ago. Updated over 1 year ago.

Status:
Closed
Priority:
High
Assignee:
Category:
osmo-bts-trx
Target version:
-
Start date:
06/24/2017
Due date:
% Done:

100%

Spec Reference:

Description

osmo-bts-trx is using regular gettimeofday() calls, i.e. a non-monotonic local system clock for its frame number timers.

This is wrong, as this clock is impacted by changes such as NTP or GPS clock synchronization.

The only relevant clock for osmo-bts-trx frame timer is the clock provided by OsmoTRX, which in turn is based on the hardware sample rate clock of the SDR board.


Related issues

Related to OsmoBTS - Bug #2325: sporadic shutdown of osmo-bts-trx in osmo-gsm-tester runs (no clock from trx)Stalled2017-06-13

Related to OsmoGSMTester - Feature #2327: document NTP as cause for failing osmo-bts-trx runs in osmo-gsm-manuals?Rejected2017-06-14

History

#1 Updated by laforge over 1 year ago

#2 Updated by laforge over 1 year ago

  • Related to Bug #2325: sporadic shutdown of osmo-bts-trx in osmo-gsm-tester runs (no clock from trx) added

#3 Updated by laforge over 1 year ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 70

I've submitted a new CLOCK_MONOTONIC based implementation at https://gerrit.osmocom.org/#/c/3037/

This implementation also contains logging of all related important events, such as missed timer executions, drift between TRX and local clock, etc.

#4 Updated by laforge over 1 year ago

  • Related to Feature #2327: document NTP as cause for failing osmo-bts-trx runs in osmo-gsm-manuals? added

#5 Updated by laforge over 1 year ago

  • Status changed from In Progress to Closed
  • % Done changed from 70 to 100

I've tested with a USRP2 while adjusting the clock manually backwards and forwards, as well as syncing to ntp from a bad base clock. Works fine now.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)