Bug #1230
High cpu load while recording in pass-throug mode
100%
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
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.
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
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!
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
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.
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.
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
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
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
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