This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Tom Tsou tom at tsou.ccOn Wed, Jun 14, 2017 at 3:47 PM, Alexander Chemeris <alexander.chemeris at gmail.com> wrote: > USB based SDRs like USRP B2x0 have hard time keeping the Tx/Rx alignment > when there are any disturbances. So osmo-trx features a sophisticated > algorithm to maintain this alignment for USB based devices. Thomas has spent > tremendous effort tuning it to perform well, but may be there are edge cases > which are not handled there yet. Let's wait for his comments. The 'clock' issue is occurring between osmo-bts and osmo-trx and not between osmo-trx and the device. For the latter, irregular packet timing would appear as underruns, overflows, late packets, etc. - errors non-specific to GSM numerology. There are timing considerations at startup because the device needs time to initialize. In the case of the B200 on first boot, the startup time is especially long because of the FPGA load. Running the uhd_usrp_probe utility will give an indication of the device initialization time. On top of that delay, osmo-trx could add another second for Tx/Rx synchronization purposes. If clock skew is not occurring at startup, then process scheduling is probably related. If the flow of CLK IND stops entirely, as in the case when osmo-trx stops running, the message would be "No clock from osmo-trx". Clock skew could also occur because of variability in calling gettimeofday(), but I have not encountered that on any systems that I run. -TT