Project

General

Profile

Bug #1230

High cpu load while recording in pass-throug mode

Added by bas t about 12 years ago. Updated about 12 years ago.

Status:
Fixed
Priority:
Normal
Category:
Streaming
Target version:
-
Start date:
2012-09-17
Due date:
% Done:

100%

Estimated time:
Found in version:
master
Affected Versions:

Description

Recording two exact same shows in mkv mode and later in pass-thrue mode and comparing the cpuload,
I noticed that when recording in pass-through mode, it takes 36% more cpu cycles.
In both situations the load is constant, only the amount differs.
I expected it to be less, being passthrough and all.

History

#1

Updated by Adam Sutton about 12 years ago

  • Category set to Streaming
  • Assignee set to John Törnblom
  • Priority changed from High to Normal

Passing to John.

#2

Updated by Adam Sutton about 12 years ago

  • Status changed from New to Accepted

I'm seeing elevated CPU load on my own system, nothing like as high as reported here but probably due to different architecture.

But I think I'm seeing something like 1-2% for MKV and 8-10% for TS.

Adam

#3

Updated by bas t about 12 years ago

Adam Sutton wrote:

nothing like as high as reported here

An increase from 2% cpu load (mkv) to 8% cpuload (ts) IMO means 400% up.
That is way more then I reported!

#4

Updated by Adam Sutton about 12 years ago

Lol,

it wasn't clear what you were reporting and its difficult to be sure that the entire increase is due to just MKV v TS as other stuff will be happening in my system all the time.

However I was just trying to point out that I'm definitely seeing an increase.

Adam

#5

Updated by John Törnblom about 12 years ago

There is more thread wakeup and mutex locking/unlocking with passthrough since the packets sent to the clients are smaller (188 bytes) than when muxing to mkv.

Claiming that the cpu load differ with 400% is a bit misleading since it depends on the actual cpu.
I've done some simple tests on some of my hardware, all using a 1080p iptv source.

streaming from vlc on one server --> tvheadend on second server --> vlc on a desktop.
Below is the cpu load (%) reported by htop.

WNR3500Lv2 (480MHz, mipsel)
---------------------------
mkv: 40-60%
pass: 48-75%

eeepc (900MHz, i686)
----------------------
mkv: 4-8%
pass: 10-20%

Intel core i5 2500K (3300MHz, amd64)
------------------------------------
pass: 8-9%
mkv: 6-7%

It might not be the most scientific method, but at least it gives you an idea of what you might gain by doing optimization.
There are some stuff that can be changed in order to reduce the load, but at the cost of code readability and maintainability.
At the moment, I don't think its worth the effort but given the right use-case, I might change my mind.

It could also be interesting to see how the load scales with multiple clients with multiple sources.

#6

Updated by bas t about 12 years ago

The right use case would be the case in which timeshift is implemented.
I've been led to the conclusion that using ts would be better then mkv, in this case.
Hence my report.
I might be wrong though.

#7

Updated by Eric Valette about 12 years ago

bas t wrote:

The right use case would be the case in which timeshift is implemented.
I've been led to the conclusion that using ts would be better then mkv, in this case.
Hence my report.
I might be wrong though.

You are perfectly right : it should be less. remuxing to mkv, you need to demux, and change the H264 stream structure. To do this you also need to read 188 bytes chunks. Regarding waling the client more frequently, you could have a look at my tree where TS streaming and storing has been enhanced (but I did not yet take the plunge to go to 3.x). https://github.com/EricV/tvheadend

#8

Updated by John Törnblom about 12 years ago

bas t:

I pushed some optimization on a new branch at https://github.com/john-tornblom/tvheadend/tree/mpegts_buf_optimization

Do you think you could give it a go?

git clone -b mpegts_buf_optimization git://github.com/john-tornblom/tvheadend.git

#9

Updated by John Törnblom about 12 years ago

  • Status changed from Accepted to Need feedback
#10

Updated by bas t about 12 years ago

Cool!
Problem solved, push it to master.

#11

Updated by John Törnblom about 12 years ago

  • Status changed from Need feedback to Fixed
  • % Done changed from 0 to 100

merged with master

#12

Updated by Adam Sutton about 12 years ago

Note: this will not be in 3.2 (yet) we've just done beta4 builds.

However we'll see about beta5 or possibly a later backport, obviously this is something we should have in 3.2 if we can.

Adam

#13

Updated by bas t about 12 years ago

Take your time, I can use master if I need to.

Also available in: Atom PDF