On Wed, Jun 14, 2017 at 04:03:44PM -0700, Tom Tsou wrote: > 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.
We are specifically wating for the "Transceiver active" on stdout to wait until the FPGA load is done. > 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. Ok, I'll try adding a little head room after receiving the "Transceiver active" message. One point may be that it's not a very powerful machine: an APU with an 800MHz dual core. > 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. With NTP switched off I have no idea why the system clock could jump around. I also looked in the root crontab and so on, maybe something is still calling ntpdate on that system... Could also make sense to wipe that OS to be sure. A lot has happened on there in the past... Will keep you posted. ~N
signature.asc
Description: Digital signature
