Attention is currently required from: pespin.
2 comments:
File src/osmo-bts-trx/scheduler_trx.c:
Patch Set #1, Line 586: * (elapsed_fn < 0) while far more wall-clock time elapsed than its FN
AFAIU "elapsed_fn < 0" is not a "FN far BEHIND our local timer", but a " FN BEHIND our local timer". […]
It's actually "far BEHIND", because:
a) the outer condition:
```
elapsed_fn > MAX_FN_SKEW || elapsed_fn < -MAX_FN_SKEW
```
b) the inner condition
```
error_us_since_clk > (int64_t)GSM_TDMA_FN_DURATION_uS * MAX_FN_SKEW
```
If it's slightly behind, we compensate for that by slowing down our own clock.
If it's far behind, we bail out with "TRX clock skew too high".
Patch Set #1, Line 597: osmo_timerfd_disable(&tcs->fn_timer_ofd);
why do we need to disable this timerfd here?
Well, it's the established pattern here in this file:
```
/* in trx_fn_timer_cb() */
463 shutdown:
464 osmo_timerfd_disable(&tcs->fn_timer_ofd);
465 bts_shutdown(bts, reason);
466 return -1;
467 }
/* in trx_start_noclockind_to_cb */
477 osmo_fd_close(&tcs->fn_timer_ofd); /* Avoid being called again */
478 bts_shutdown(bts, "No clock since TRX was started");
479 return -1;
480 }
```
and this is exactly what we do in the case of a "PC clock skew too high" event.
By doing so, we immediately stop transmitting DL bursts because we're out of sync with the transceiver and there's simply no good reason to keep transmitting. IIRC, in the absence of Uplink bursts the transceiver (at least osmo-trx) fills the buffer with dummy bursts, so we should be fine during ramping down (not an abrupt power off).
To view, visit change 42851. To unsubscribe, or for help writing mail filters, visit settings.