Osmocom test suites in TTCN-3 (Eclipse Titan)
https://osmocom.org/projects/core-testing-infra
Vadim Yanitskiy
e9c0635dae
Since change [1] has been merged, we see multiple regressions in ttcn3-bsc-test (all LCLS test cases) and ttcn3-bsc-test-sccplite (sporadic failures). In all failed cases, the reason is similar: RSL for unknown Dchan BSC_Tests.ttcn:4501 BSC_Tests control part BSC_Tests.ttcn:2176 TC_assignment_codec_fr testcase The mentioned change enables TCP_NODELAY option for all IPA based connections, including both OML and RSL. This option disables Nagle's algorithm [2], so we get less delays on IPA based links. It took me a lot of time to investigate, and finally, I figured out what is actually causing those regressions. The TCP_NODELAY itself is not a problem, of course. As it turned out, the problem is here, in our TTCN-3 test case framework. Each test case involves several components (actors) running in parallel. One of them is RSL_Emulation_CT, which is responsible for handling and routing of RSL messages between the connected components. A test case may register dedicated channel handlers by calling f_rslem_register(), so DCHAN/RLL/IPACCESS messages will be matched by RslChannelNr/TrxNr and routed to the corresponding one. If no handler is found for a given RSL message, the RSL_Emulation_CT would abort the test case execution. And that's where the problem is. Given that all components are running in parallel, it may happen that a received RSL message would be processed by the RSL emulation component faster than the test case would call f_rslem_register(). The test case would be aborted due to "RSL for unknown Dchan". Speaking in context of the failing BSC test cases, a test case calls f_rslem_register() on receipt of an Assignment Command as it contains all the assignment parameters. After that we expect to receive an RSL ip.access CRCX for that channel. The problem is that both Assignment Command and ip.access CRCX messages are sent by the BSC simultaneously, so the later may be handled faster than the first one. Race condition! Let's work this around by maintaining a waiting queue, where the messages, for which no handler was found, will be kept until the corresponding dedicated channel is registered. This is an optional feature that needs to be enabled explicitly by calling f_rslem_dchan_queue_enable(), and then explicitly disabled by calling f_rslem_dchan_queue_disable(). If at the moment of calling f_rslem_dchan_queue_disable() the waiting queue is not empty, e.g. because the IUT sent us more messages than we expected, test execution will be terminated. The actial fix for the LCLS test cases will be submitted next. [1] Ia3d4c41bf0659e682f0b7ae5f3d58ed0f28edb58 [2] https://en.wikipedia.org/wiki/Nagle%27s_algorithm Change-Id: I25e10e28de174337233e6a3bb32cc16f2d7d614e Related: OS#4619 |
||
---|---|---|
COMMON | ||
ROHC_CNL113426_LATEST | ||
SCCP_Test | ||
asn-test | ||
bin | ||
bsc | ||
bsc-nat | ||
bts | ||
ccid | ||
deps | ||
doc | ||
ggsn_tests | ||
hlr | ||
lapdm | ||
library | ||
mgw | ||
mme | ||
msc | ||
pcu | ||
pgw | ||
remsim | ||
sccp | ||
selftest | ||
sgsn | ||
simtrace | ||
sip | ||
stp | ||
sysinfo | ||
.gitignore | ||
.gitreview | ||
Common.cfg | ||
Makefile | ||
compare-results.py | ||
gen_links.sh.inc | ||
log_merge.sh | ||
mask_expected_results.sh | ||
regen-makefile.sh | ||
rmlinks.sh | ||
start-testsuite.sh | ||
ttcn3-tcpdump-start.sh | ||
ttcn3-tcpdump-stop.sh | ||
update_expected_results_from_jenkins.sh |