osmo-bts-trx: "No clock from osmo-trx"

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/.

Neels Hofmeyr nhofmeyr at sysmocom.de
Fri Jun 16 18:20:35 UTC 2017


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20170616/e26e52c2/attachment.bin>


More information about the OpenBSC mailing list