Performance issues

[hsteinhaus]

I am running minisatip on a rather small embedded board (Dragonboard 410), which is generally working fine. However, minisatip consumes quite a lot of CPU power and also causes a bit more heat buildup than initially expected.

A short glimpse on "top" reveals, that the majority of load is system load, i.e. it is not caused by some difficult calculations. strace reveals, that there is an enormous frequency of system calls in the worker threads, mainly write() and poll().

Is this really caused by the way minisatip is working or is there some potential for optimization, e.g. by reading/writing bigger chunks or so?

[catalinii]

Hi,

Unless you watch encrypted channels that uses dvbcsa (-o option) to decrypt you should not see high load from minisatip. Basically minisatip does poll, read, write loop for every adapter and the amount of data that is read depends on -b parameter.

If you do not watch encrypted channels then feel free to upload the log

[hsteinhaus]

No encrypted channels involved and no cams/softcams installed. My DVB source for this test is a Netceiver with one double-S2 card installed. The VDR with SAT-IP plugin (configured to use two tuners) was displaying one HD channel and probably EPG-scanning on the second. I have increased the buffers by a factor of 4 from the numbers mentioned as default in the help message.

I have just recorded two strace dumps of the most active threads - one of the worker threads (strace2.txt) seems to do more than 6000 syscalls per second. The observed load of 30-35% of a core seems to be reasonable for that load pattern, even if the syscalls wouldn't do anything (the SnapDragon 410 cores are not really strong - low-cost smartphone style hardware). The OS is Linaro Buster 18.01 (an arm64 Debian variant with kernel 4.14.0).

For the test, minisatip was launched with this command line: /usr/bin/minisatip -f -b 288768:23101440 -g --netceiver eth0:2

[hsteinhaus]

strace2.txt strace1.txt

[perexg]

BTW: I am using this patch for satip-axe (which has also limited CPU power):

diff --git a/src/stream.c b/src/stream.c
index bde2992..8443a4f 100644
--- a/src/stream.c
+++ b/src/stream.c
@@ -987,7 +987,7 @@ int process_dmx(sockets *s)
 #endif

        rlen = ad->rlen;
-       int packet_no_sid = check_cc(ad);
+       const int packet_no_sid = 0 /* check_cc(ad) */;

        if (ad->sid_cnt == 1 && ad->master_sid >= 0 && !packet_no_sid) // we have just 1 stream, do not check the pids, send everything to the destination
        {

So you may give a try. It removes the CC checking code which is not really necessary.

[perexg]

My suggestion probably won't help much after looking to straces. The minisatip should use recvmmsg() syscall to gather more UDP packets from the input side and process them in batch.

[catalinii]

@hsteinhaus, Does the first suggestion helps ? (const int packet_no_sid = 0)

I think for receiving a bigger chunks are u using the satip client ? If yes is possible to switch to TCP (-O) ?

[lars18th]

I've implemented a PR that uses of the recvmmsg() syscall in the read function of the satipc module: #827 . Please, check it and if it solves your problem, then I suggest to close this issue.

Regards.

[Jalle19]

Bot h the CC checking code and recvmmsg usage has been added since this ticket was created, so let's close this one.