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/gerrit-log@lists.osmocom.org/.
Pau Espin Pedrol gerrit-no-reply at lists.osmocom.orgPatch Set 1: > (1 comment) > > I'm not sure I understand the max_trx. Which situation does it > resolve? AFAIU a BTS simply has a given number of TRX by hardware, > and a scenario may want to request a specific number of TRX (but I > guess will generally not actually care how many there are). Who > dictates a max there? If we have a max, why no min? > > Once we have a good explanation, that should go in the code > somewhere and not be "hidden" in the commit log. It's not hidden in the commit log, it's explained: "If a num_trx value higher than max_trx is specified throuygh config file or at runtime by the test, an exception is raised explaining the issue." So it's mainly a catch-misconfigurations issue. With this easy knowledge (how many TRX suport at max that BTS) we can verify that the config is fine, or prevent some test to programatically use/configure more TRX than available for that specific BTS class/object. This avoids debugging why stuff is not working just to find out something went wrong when trying to configure the BTS with too many trx. -- To view, visit https://gerrit.osmocom.org/8061 To unsubscribe, visit https://gerrit.osmocom.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I7f46eaf7a16f03268653299c93600c0443f691ac Gerrit-PatchSet: 1 Gerrit-Project: osmo-gsm-tester Gerrit-Branch: master Gerrit-Owner: Pau Espin Pedrol <pespin at sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de> Gerrit-Reviewer: Pau Espin Pedrol <pespin at sysmocom.de> Gerrit-HasComments: No