Useful to debug realtime issues, for example when calling a periodical
routine, if it's not programmed carefully enough, it may be that the first
call takes way longer than the next ones (for example it uses some memory
that is not mapped in the process, leading to many page faults the first
time it's executed).
Having a periodic log for the timing of this routine with min/avg/max/count
will reveal that a call is way longer than average and will help in
finding where exactly in the code the time is spent, thanks to the ease
of use of the T tracer; you put T(T_XX, T_INT(1)) just before the code
you want to measure, you put T(T_XX, T_INT(0)) just after and time_meas
will show the delta time between those events. Then you cut the routine
in smaller pieces, measure with T(1)/T(0), and you finally reach the small
guilty part that takes too long.
In time_meas.c, when getting 0 for the event, we log delta time with
previous 1 for the event. "start_valid" was not cleared, so receiving
a second 0 without 1 in between may lead to wrong logging.
Should not happen in practice, but still, little bug.
(Note: we don't protect against streams of 1, but this case should also
not happen.)
MIB, SIB1, random access and regular scheduling are traced.
At the beginning of a connection (rrc setup request and rrc setup), the
RNTI is reported as 0. Might be fixed, somehow, if absolutely needed (not
sure).
T_MAX_ARGS was 16 and some people start to use the T machinery with
more than 16 values. So be it. Let tracers be friendly and accept 32.
(More commits to follow for full support.)
Also why is T_MAX_ARGS in T_defs.h when it's only used by event.h?
Hum?
When using the make system to generate T files, if you change
T_messages.txt you may have problems compiling the gnb with ninja.
If you want to see the problem:
First run: cd cmake_targets; ./build_oai --ninja --gNB
Then: cd common/utils/T
edit T_messages.txt, add a trace, for example:
---
ID = ENB_PHY_UL_TOCK
DESC = eNodeB uplink tick - one tick per ms at start of uplink processing
GROUP = ALL:PHY:GRAPHIC:ENB
FORMAT = int,eNB_ID : int,frame : int,subframe
---
then run: make
then: cd cmake_targets/ran_build/build; ninja nr-softmodem
You should have an error looking like this:
---
[3/81] Checking validity of VCD files
FAILED: common/utils/T/CMakeFiles/check_vcd /tmp/develop/cmake_targets/ran_build/build/common/utils/T/CMakeFiles/check_vcd
cd /tmp/develop/cmake_targets/ran_build/build/common/utils/T && /tmp/develop/cmake_targets/ran_build/build/common/utils/T/_check_vcd /tmp/develop/common/utils/T/T_messages.txt /tmp/develop/common/utils/T/../LOG/vcd_signal_dumper.h
error: VCD_FIRST_VARIABLE is not correct in T_defs.h
You probably added a VCD trace (variable or function) but you did not
update T_messages.txt and/or T_defs.h in common/utils/T/
[...]
---
Let's first isolate the generated T .h files when using make because
we have two versions of T_IDs.h and T_messages.txt.h when mixing
make/cmake.
A next commit will regenerate T_IDs.h and T_messages.txt.h when
T_messages.txt chages for the cmake system, because this commit
does not solve the problem.
There is already common/utils/config.h. This file(name) is hardcoded as
it is included into asn1c, and cannot be renamed. To avoid a name clash
and confusing, we rename T's config.h/c to configuration.h/c.
The T tools offering a GUI use libxft as a dependency. By default, we
try to limit the amount of dependencies, but libxft comes with X11.
Put the GUI tools behind cmake option T_TOOLS_GUI (default: off) to only
build on demand with a cmake option.
- Add CMakeLists.txt to build all T tracer user tools
- Previous Makefiles are retained in common/utils/T: you can do
$ cd common/utils/T/tracer
$ make # all executables are there
or also
$ mkdir build && cd build
$ cmake .. -GNinja
$ ninja T_tools # all executables are in build/common/utils/T/tracer
Minimalist gnb tracer to trace (for the moment) rxdataF when some
decoding for PUCCH or PUSCH has been done.
Important: T_BUFFER_MAX and T_CACHE_SIZE have been changed. T_BUFFER_MAX
is twice as big as before. T_CACHE_SIZE has been devided by two. Globally,
the memory usage of the T tracer is the same, but since we divided by two
the number of buffers in the cache, we may hit some realtime problems if
all the buffers are busy at some point. The simple solution would be to
use 8192*2 for T_CACHE_SIZE as it was, but then we double the memory usage
of the T tracer. This, or another solution, to be defined.
There was a problem with several UEs in the wireshark log. It seems that
wireshark needs the UE id otherwise it gets confused and sees retransmissions
where it's just another UE connecting and doing the same as a previous
UE.
Let's put kind of a UE id. Each RNTI seen by macpdu2wireshark gets an UE id
assigned the first time it's seen in a trace.
This is a bit hackish but seems to be fine.
We could have added UE_id in all the traces, that is change the T() calls
in the softmodem. It was less work to do it as it is, ie. only touch
macpdu2wireshark.c.
The RAR uses the same UE id all the time, may be a problem. To be refined
if needed.
The T tracer macpdu2wireshark has been modified to handle the new traces.
The usage is the same as for LTE.
In NR the RACH is logged as an LTE RACH. Maybe we'll change that in the
future. Looking at the source code of wireshark, I could not find any
way to report NR RACH. Maybe they forgot it. Or I did not search correctly...
also correction for Circular Dependency Protection on header files
also correction on the banner check
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>
Cedric Roux