Change in osmo-ttcn3-hacks[master]: bts: Add module parameters with tolerance to support real HW

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

Harald Welte gerrit-no-reply at lists.osmocom.org
Wed Sep 26 19:59:14 UTC 2018


Harald Welte has posted comments on this change. ( https://gerrit.osmocom.org/11083 )

Change subject: bts: Add module parameters with tolerance to support real HW
......................................................................


Patch Set 2:

(4 comments)

https://gerrit.osmocom.org/#/c/11083/2/bts/BTS_Tests.ttcn
File bts/BTS_Tests.ttcn:

https://gerrit.osmocom.org/#/c/11083/2/bts/BTS_Tests.ttcn@58
PS2, Line 58: mp_tolerance_ms_power_level
> If I recall correctly, what I read is that the value should match only if the MS supports it, and if […]
Yes, it is correct that a MS that doesn't support the given power level will return a different (supported) one.  However, the BTS/BSC will know the power capabilities of the phone, and we are testing with a known phone.  So I'm saying we know the setup well enough to not ever ask for a power level not supported by the device.


https://gerrit.osmocom.org/#/c/11083/2/bts/BTS_Tests.ttcn@58
PS2, Line 58: mp_tolerance_ms_power_level
> Yes, I get power level 0 sometimes (using mp_ms_power_level_exp=7 and mp_tolerance_ms_power_level=0) […]
is that sometimes in between, or is that only the first message ever sent by the phone?  Maybe it's just the initial state that's somehow broken? Or the power control loop needs a few iterations until it arrives at the intended value? In this case we could simply exclude the first N messages from matching.


https://gerrit.osmocom.org/#/c/11083/2/bts/BTS_Tests.ttcn@59
PS2, Line 59: mp_tolerance_ms_actual_ta := 0;
            : 	integer mp_tolerance_timing_offset_256syms
> Regarding this comment, now I understood that only the 2 tolerance ones are to be merged, not the ex […]
the 256syms can of course be non-multiple of 256.  But you can specify the tolerance in units of 1/256th (e.g. 512 for two symbols), and then you can compute the TA tolerance as 512/256=2 and the toa256 tolerance is 512.


https://gerrit.osmocom.org/#/c/11083/2/bts/BTS_Tests.ttcn@62
PS2, Line 62: mp_ms_power_level_exp
> As I said, I'll test it a bit more and come back with some descirption or change.
there is of course the power control loop, and we may have bugs in the power control loop implementation.  Also, there are differences in how the different BTS models / PHY implementations handle this.  The BSC may also instruct the BTS to bypass BTS-side power control loop, whihc AFAIK is broken / not implemented.

I'm not arguing that your observations / results are wrong.  I'm just arguing that somehow our code is broken / incomplete and we shouldn't adjust this by increasing the test tolerance, but by looking for the actual issue.



-- 
To view, visit https://gerrit.osmocom.org/11083
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: Icf1d2216d29c1ebf68c672e6ca06c54a7457304b
Gerrit-Change-Number: 11083
Gerrit-PatchSet: 2
Gerrit-Owner: Pau Espin Pedrol <pespin at sysmocom.de>
Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-Reviewer: Pau Espin Pedrol <pespin at sysmocom.de>
Gerrit-Comment-Date: Wed, 26 Sep 2018 19:59:14 +0000
Gerrit-HasComments: Yes
Gerrit-HasLabels: No
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20180926/85555669/attachment.htm>


More information about the gerrit-log mailing list