These should have been ExecStopPost from the beginning. Currently
they reset the firmware while the software is starting. Reload
the DSP and FPGA firmware.
The latency to respond to a PH-READY_TO_SEND.ind may not be higher
than 18ms. Currently we are using nice to increase our priority but
for a heavily loaded cell this is not enough. Add an option to enable
realtime scheduling and use it in the screenrc.
Linux offers two realtime scheduling classes these are SCHED_FIFO
and SCHED_RR. For SCHED_FIFO the process is running as long as possible
(potentially taking all the CPU and never yielding it), for SCHED_RR
the process can still be pre-empted at the end of the timeslice.
Using SCHED_RR appears to be the more safe option as a run-a-way
sysmobts process will not be able to take all the CPU time.
For a very loaded cell we also require to use readv/writev to allow
writing multiple primitives in one syscall.
Make the script mostly unkillable due to OOM and make sure that the
process has a score of zero. Wait 10 seconds before re-launching.
The combination of ( && exec ) & appears to save one sub-process. The
script has been tested with bash and busybox's ash.
AGCH is reported as part of the PCH because we are not searching
for the BS-AG-BLKS-RES inside the SI3 and do not use MphConfigReq
to change this setting.
We only need to run this once and we know the clock error. In case it
is 0/0 we know that we didn't receive one of the two clocks. This could
be because the GPS doesn't have a fix. I accidently pushed this code into
the master branch and it is too late to rebase.
We need to read the Layer1 message queues fast enough, switch on
realtime processing for that. Move the firmware init after the
process execution to have some time for the firmware to reload
before the application sysmobts is restarted.
Migrate the LED and firmware reloading into a systemd service. This
makes the respawn and screen obsolete as it will be done with systemd
and the journal script.
This starts sysmobts-remote and dumps the documentation about the
VTY to the doc/ directory.
$ ./contrib/dump_docs.py
this writes doc/vty_reference.xml
From our header files v2.4 onwards, we include some macros that allow us
to do compile-time checks for the API header version. As older headers
don't have those macros, we have to fall back to assume it will be v2.2
It has been tested with the OCXO and the network listen mode of the
firmware. For other sources we are not required to synchronize to
the network and the tool needs to be adjusted.
Once we get RF-ACTIVATE.conf from L1, we now enable the corresponding
LED. We also switch it off on RF-DEACTIVATE.conf. We do _not_ switch
it off when osmo-bts crashes or terminates before RF-DEACTIVATE.conf.
The latter is intentional, as RF may very well still be active at that
point. The re-spawning script will re-set the DSP and therby turn off
the RF and then disable the LED.
A better solution might be to do all this in the kernel driver for the
DSP.
Holger Hans Peter Freyther
Harald Welte