Attention is currently required from: pespin.

fixeria has posted comments on this change by fixeria. ( 
https://gerrit.osmocom.org/c/osmo-bts/+/42851?usp=email )

Change subject: osmo-bts-trx: shut down on stale clock indication from 
transceiver
......................................................................


Patch Set 1:

(2 comments)

File src/osmo-bts-trx/scheduler_trx.c:

https://gerrit.osmocom.org/c/osmo-bts/+/42851/comment/8b794935_54048ba7?usp=email
 :
PS1, 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".


https://gerrit.osmocom.org/c/osmo-bts/+/42851/comment/1286a776_c735231e?usp=email
 :
PS1, 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 https://gerrit.osmocom.org/c/osmo-bts/+/42851?usp=email
To unsubscribe, or for help writing mail filters, visit 
https://gerrit.osmocom.org/settings?usp=email

Gerrit-MessageType: comment
Gerrit-Project: osmo-bts
Gerrit-Branch: master
Gerrit-Change-Id: If787ab7ed70aa2dcb0389ceb58620c2302c3431a
Gerrit-Change-Number: 42851
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <[email protected]>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: laforge <[email protected]>
Gerrit-CC: pespin <[email protected]>
Gerrit-Attention: pespin <[email protected]>
Gerrit-Comment-Date: Sat, 20 Jun 2026 07:03:58 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <[email protected]>

Reply via email to