Attention is currently required from: neels.
iedemam has posted comments on this change. (
https://gerrit.osmocom.org/c/osmo-bsc/+/28165 )
Change subject: stats: new trackers for lchan life duration (v2)
......................................................................
Patch Set 4:
(1 comment)
Patchset:
PS4:
I don't see any stats reporting in this patch
anymore. This is only about VTY output?
The commit log says "stats".
The function bts_store_lchan_durations() stores duration values in the stats system after
summing across all lchans. I'm already using these values in production and comparing
to our previous approach. They are tracking well.
IMHO it would be better to fix the performance problem
in osmo_time_cc.
The way this patch avoids performance issues is to reduce the timer callback to 1/s,
No, the biggest improvement is only using one timer per BSC instead of one timer per
lchan.
Of course we can reconfigure osmo_time_cc to trigger
timers only once per second.
It may be necessary to separate the granularity from the update timer period,
then we can get milliseconds precision while updating that value less often.
Another fix is to have only one single timer callback that updates all active
osmo_time_cc. Like that we can have active lchan tracking in millisecond precision
for *any* number of lchans with only a single timer in select() for all of them.
This would reduce the select() load by a factor that is the number of active lchans,
in production environments this is more than factor 10 (as this patch does).
I think we're just turning things inside out at this point then. Why add any timer
logic at all to each lchan when they will all be externally controlled and triggered? The
only thing each lchan needs to know about itself is a couple of timestamps.
osmo_time_cc made problems because it is fairly new
code that tries to solve a
pretty complex problem in a generic way, and I built some problems into it.
IMHO it is worth it to make that work, so that iedemam's patch will perform well.
If you were free to implement all of the above suggestions, I might vote this way as well.
However, I don't think you have much free time on your hands given the delay in each
response. This is not a criticism, just being practical in solving the problem at hand.
--
To view, visit
https://gerrit.osmocom.org/c/osmo-bsc/+/28165
To unsubscribe, or for help writing mail filters, visit
https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-bsc
Gerrit-Branch: master
Gerrit-Change-Id: Ie3771233ecbd4bc24a24fb22c1064a18e7b8b2b0
Gerrit-Change-Number: 28165
Gerrit-PatchSet: 4
Gerrit-Owner: iedemam <michael(a)kapsulate.com>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
Gerrit-CC: laforge <laforge(a)osmocom.org>
Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Comment-Date: Wed, 25 May 2022 12:02:37 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de>
Gerrit-MessageType: comment