Patch Set 1: > I would actually vote for making SCHED_RR a default, preferrably > with an even higher priority (e.g. 10) than what we'd use as > osmo-bts-trx, as osmo-trx is even more important to schedule than > osmo-bts. What do you guys think?
These settings can be very tricky. osmo-trx already sets SCHED_RR and priorities through the UHD priority interface. https://github.com/EttusResearch/uhd/blob/master/host/lib/utils/thread_priority.cpp But, importantly, the current settings were added years ago to be independent of underlying UHD libusb threads - which may not be ideal. UHD maintains a separate internal thread for driving libusb asynchronous I/O. That thread is indirectly controlled by the priority level at the time of construction - which is main() in osmo-trx. So this patch could perform better than the current priority settings. Does testing confirm that? -- To view, visit https://gerrit.osmocom.org/3080 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia2452b9763960b2be37fbeee9d832554da68a53f Gerrit-PatchSet: 1 Gerrit-Project: osmo-trx Gerrit-Branch: master Gerrit-Owner: Harald Welte <lafo...@gnumonks.org> Gerrit-Reviewer: Harald Welte <lafo...@gnumonks.org> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Tom Tsou <t...@tsou.cc> Gerrit-HasComments: No
