On Wed, Jun 14, 2017 at 3:47 PM, Alexander Chemeris alexander.chemeris@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