Question: CPU utilisation

[reidjr]

Jumping back to sasc-ng for some testing I noticed ffdecsawrapper/descrambler seems to utilise a lot more CPU and does not release it when descrambling stops. Not really a scientific test, And the values obviously jump around but:

Ubuntu 12.04/sasc-ng/mythtvbackend 0.27

CPU load: Decoding and watching NPO1 mythbackend 8% sasc-ng 4% Back to Gui screen mythbackend 1% sasc-ng ~0%

Ubuntu 16.04/ffdecsawrapper/mythtvbackend 0.28

CPU load: Decoding and watching NPO1 mythbackend 3% ffdecsawrapper 9% Back to Gui screen mythbackend <1% ffdecsawrapper 8%

The CPU load displayed by top stays above 7% continually for ffdecsawrapper.

Have you noticed this before ?

[bas-t]

I'll have a look, but since you (afaik) use ubuntu mythtv packages (that I've never liked), please first shutdown mythtv and see if ffdecsawrapper idles as it should. I guess not, as NPO1 should not even be scrambled, afaik that's been regulated by law.

[bas-t]

Hmm, my backend is recording 3 encrypted HD shows atm and top says that ffdecsawrapper uses around 3,9% of the available cpu cycles for that, and mythbackend slightly more, around 4.1%.

That's a dual core "Ivy bridge" pentium G2030@3.00GHz. I'll take a look again when it's idle.

Mind you, I'm running Debian Jessie, compile my own kernel with dvblooback intree, I use the somewhat more advanced 'descrambler' repo and last but not least: I've had nothing but trouble (meaning some instability issues) with whatever mythtv packages in the past, either Debian or Ubuntu, so I allways compile it myself.

[bas-t]

Ok, it's idle now and top says ffdecsawrapper uses around 0,5% of the available cpu cycles. That more or less matches your 12.04 system.

[bas-t]

Update: the previous reading from top was running a 3.16 kernel. Running a 4.7.2 kernel, ffdecsawrapper idles at 0%. Going to build a 4.8-rc5 kernel now, see what happens.

[bas-t]

OK, bottomline: depending on the gcc version used and the kernel series you use, the amount of cpu cycles that ffdecsawrapper uses when active, can vary quite a bit. But when idle it should be well below 1% in all cases. Take in mind that most modern cpu's only use a small amount of the capability they have when idle. Like 50% or less. Top does not know about it, it thinks that the cpu is running at it's max speed and compares to that. So it can be that top reports 3% when it actually should be 1%, etc. Well I guess you get my drift. Moreover, when you use a dual core cpu, top compares only with the capability of one core. So under heavy load, ffdecsawrapper theoretically could use like 160%, according to top. So allways divide that number by the number of cpu cores you have.

[reidjr]

Sorry, just saw your reply.

Sadly NPO1/3 are scrambled, it used to be free to view on satellite ( scrambled but you could get a free card) As far as I know now you have to pay for it as part of a package.
I hate % as well, as it depends what 100% means :-)

I'm running on a dual core Intel G540 @ 2.50GHz, so similar architecture.

Looks like you are getting expected behaviour and I am not. When I start ffdecsawrapper, and mythtvbackend, then there is no noticable cpu utilisation from ffdecsawrapper. As soon as ffdecsawrapper is active, then it stays active. It continues to use the same cpu load when either you switch away from an encrypted channel, or you close down mythtv-backend.

I went back and checked using the descrambler (ffdecsawrapper) instead of sasc-ng, on 12.04. (3.5.0 ubuntu kernel) and sasc-ng does idle, but ffdecsawrapper continues to use the same cpu load when either you switch away from an encrypted channel, or you close down mythtv-backend.

The absolute utilisation during decoding is not a concern, but the lack of idling seems wrong. Any hints how I can diagnose why its not idling, as it obviously works fine for you . Could you paste the options you run it as a quick check, or any compile options that are not straight from your excelent ./configure defaults ?

[reidjr]

ok, did a fresh compile ( straight ./configure ) from: master descrambler, master ffdescawrapper, and oldstable ffdecsawrapper. The binary from oldstable works as expected. 3-4% when descrambling 0% when its idle. The master versions use 7% + all the time. So a quick fix for me is to use the old stable branch, as it does what I need, but happy to help diagnose where it goes wrong .

[bas-t]

Well, I use master branch from descrambler. But anyhow, you're fine, so I'm closing this ticket.

[reidjr]

probably bad to add to a closed ticket, but the issue for me seems to be

sc/PLUGINS/src/network.c

replacing network.c with the version from acc067c920cdbaec8bce87ba2979f10e3a003a30, removed the high CPU symptoms from HEAD for me.

[bas-t]

And by HEAD I guess you mean 'master HEAD'

I failed to find any version of network.c with git hash acc067c920cdbaec8bce87ba2979f10e3a003a30, so what do you mean?

[reidjr]

yes, Master HEAD. (Descrambler or FFdecsawrapper)

All I was trying to say was either Descrambler master or ffdecsawrapper master work for me without cpu load, as long as I revert the changes to network.c. Its that commit that is causing me grief. Thats why oldstable does not have the cpu isue, as those commits didn't happen in that tree.

Descrambler tree doesnt go far enough back, so I pulled the older version from the FFdecsawrapper repository. August the 4th 2014, before the commits tagged "mrfloppy82 Update network.c"

I only just understood the confusion :-) I was giving the git hash of the whole tree, not the individual file. I didnt even know you could do that :-(

As always, thanks for your work.

[bas-t]

OK, I get it. The million dollar question still has to be answered: why the f*ck does that change on network.c not have any (noticeable) impact on my setup, where it certainly hurts yours? I'm planning on investigating, when time permits. Of course, you're welcome to beat me to it! In the meantime and for your convenience, I've created a oldstable branch in descrambler, reverting those changes.

[bas-t]

Hi, I still cannot reproduce your issue, so I asked the author of the (for you at least) offending code to review it, based on your struggle. Hope he can help you out here.

[reidjr]

Thanks, for both the review and the new(old) branch. The issue shows up on both 12.04 and 16.04 LTS Ubuntu desktop versions I can test against. The only vague Idea I had was to check what protocols you/I am running as key servers. I have a local card, but connect via CCCam protocol. Are you using newcamd or some other local card server ?

I'll try swapping the oscam protocol and see if that makes a difference.

[reidjr]

Ok, using cccam2 in cardclient.cfg gives the high CPU load, with the network.c update. ( this is my normal config ) Reverting network.c update allows normal load and idle.

Running newcamd there is no high cpu, and normal idle in either version of network.c.

So I assume the difference was that you are running newcamd server on oscam ?

[bas-t]

I'm using newcamd.

[bas-t]

cccam has some known issues that probably never will get fixed. Unless someone volunteers to do so, that is. @mrfloppy82: never mind, this seems to be sorted out. Closing, again...

[reidjr]

But why does it work without the patch :-) Purely academic intrest. Do you think it is the cccam2 code in original sc that is at fault, or at least its interaction with the network code ? I agree its not worth your or anybody elses bandwidth to fix, as there are two workarounds ( don't use mrfloppys commit, or don't use cccam ).

thanks again.

[bas-t]

Frankly, I couldn't care less. As i said, I'll never be looking into cccam code. I've never been affected by mrfloppy82's patches in a negative way, cccam has known issues, do the math.

[bas-t]

FYI: I renamed th oldstable branch to 'cccam'. Oldstable was misleading.

[reidjr]

Thanks:-) I had temporarily stopped using cccam2 line in smartcard.conf to avoid the Cpu load, and moved to newcamd as you seem to favour it. But I found that on my setup, that newcamd seems to lose connection with the local oscam card server, and then it does not try to reastablish. The local oscam/cccam2 works consistantly, and doesnt lose connection, so Just yesterday I started using cccam again. So thanks :-)

On Sunday, 2 October 2016, Tycho Lürsen notifications@github.com wrote:

FYI: I renamed th oldstable branch to 'cccam'. Oldstable was misleading.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bas-t/descrambler/issues/7#issuecomment-250959671, or mute the thread https://github.com/notifications/unsubscribe-auth/AHAZ_IZn72TlyOSlCpKPfpsN1e_YnImRks5qv2hygaJpZM4J0mMw .

Sent from Gmail Mobile

[bas-t]

Yeah, it can be quite a headache to figure out a stable combination with oscam, I've had my fair share of trouble too when I started this project. Might be the version of oscam you use (some are plain broken), or some simple misconfig, or whatever... Anyway, as soon as you're satisfied with the result of having poked around, by all means stick to it.

Cheers!

[bas-t]

I'm removing the stable and cccam branches.

[reidjr]

Thanks for letting me know, I think I'm ok as long as I use newcamd. Weird coincidence I just updated my kernel and rebuilt yesterday after 3 months of stability :-)

On Tue, 22 Nov 2016 at 20:55, Tycho Lürsen notifications@github.com wrote:

I'm removing the stable and cccam branches.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bas-t/descrambler/issues/7#issuecomment-262362966, or mute the thread https://github.com/notifications/unsubscribe-auth/AHAZ_BiXdxEwozFkLAqBc16cncescAvNks5rA1bUgaJpZM4J0mMw .

[bas-t]

I love that word: stability