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