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/.
Max msuraev at sysmocom.deWhich branch is used in practice? I've looked at gerrit/fairwaves/master and the difference seems pretty small so I'm puzzled as to which commit fixes it. On 06/13/2016 08:39 PM, Alexander Chemeris wrote: > On Mon, Jun 13, 2016 at 7:04 PM, Harald Welte <laforge at gnumonks.org> wrote: >> On Mon, Apr 11, 2016 at 05:04:13PM -0700, Tom Tsou wrote: >> >>> Related is the question of when osmo-trx should send CLOCK >>> indications. Right now a CLOCK indications is sent with arrival of >>> commands on the control interface. After starting, CLOCK indications >>> are sent at an one second interval (216 frames). The indications sent >>> from the control interface are why osmo-bts is receiving CLOCK so >>> early. >> I don't know, to be honest. I didn't write osmo-bts-trx. Other PHY >> layers we interact send us information on the GSM frame number with >> every frame number increment. >> >> We also receive PH-ReadyToSend.ind in line with GSM PHY layer >> specifications for each frame to be sent. osmo-bts simply responds to >> those and all clock handling is entirely in the PHY. >> >> As osmo-trx dosen't do that (it's only half of a PHY layer), the >> missing part (scheduler) is implemented inside osmo-bts-trx. This >> scheduler is then generating the equivalent of the PH-ReadyToSend.ind >> towards the L1SAP and the common part of OsmoBTS. >> >> So in osmo-bts-trx it seems that there is code in trx_sched_clock() that >> tries to generate the frame numbers locally in between perios of no >> "CLOCK IND" from osmo-trx by starting an osmo_timer for it. This seems >> a bit ugly but of course reduces the number of UDP packets that we need >> to process. >> >> If osmo-bts-trx users have not experienced any timing related issues, I >> think there is no reason to introduce any changes itno this part, i.e. >> keep the frequency of the "CLOCK IND" frames as-is, to also remain >> compatible with other OpenBTS-like transceiver implementations. > I don't remember issues with this part, but looking into the code I > don't see much log printing there, so even if we encountered them, > they probably wen unnoticed. Which is not a good behavior. > > I personally think that sending CLOCK IND every frame is a good idea. > if we do this, we only need to check for lost CLOCK IND's and the code > becomes much simpler. We're already sending 8 times more UDP packets > even in idle mode (8 downlink bursts per frame), and 16 times more in > fully loaded mode (downlink + uplink), and if we're running multi-TRX > system, than proportion is even higher. We can do more 'perf' > monitoring, but my feeling is that the impact will be a minor. If we > find that UDP adds significant overhead, we can switch to a more > efficient IPC (UNIX sockets?), but I seriously doubt that this will be > needed. > > As a side note, we (Fairwaves) will be able to look into these issues > deeply only in a few months in the best case. So if there are any > volunteers who want to get all these issues fixes before that, don't > hold your breath. > -- Max Suraev <msuraev at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte