Bug #2339
closed
osmo-bts-trx uses non-monotonic system clock for frame number timer
Added by laforge almost 7 years ago.
Updated almost 7 years ago.
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 to Bug #2325: sporadic shutdown of osmo-bts-trx in osmo-gsm-tester runs (no clock from trx) added
- 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.
- Related to Feature #2327: document NTP as cause for failing osmo-bts-trx runs in osmo-gsm-manuals? added
- 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