Re: [vdr] [PATCH] Fix TS buffer thread high CPU usage

2016-03-20 Thread glenvt18
Yes, I too don't see how it can be harmful. In case you want to collect statistics, I did it with this patch (for a single device): http://pastebin.com/6NAVNMda Best, Sergey Chernyavskiy. 2016-03-20 16:07 GMT+03:00 Klaus Schmidinger : > On 18.03.2016 22:14, glenvt18

Re: [vdr] [PATCH] Fix TS buffer thread high CPU usage

2016-03-20 Thread Klaus Schmidinger
On 18.03.2016 22:14, glenvt18 wrote: UPDATE. Here are 60 Mbit/s (entire transponder) test results: http://pastebin.com/nHDN8nsW - the same behaviour as for 30- Mbit/s, no huge chunks on the second read. Threshold value of 7 was chosen for demonstration only. It's just a bit smaller than

Re: [vdr] [PATCH] Fix TS buffer thread high CPU usage

2016-03-19 Thread glenvt18
UPDATE. Here are 60 Mbit/s (entire transponder) test results: http://pastebin.com/nHDN8nsW - the same behaviour as for 30- Mbit/s, no huge chunks on the second read. Threshold value of 7 was chosen for demonstration only. It's just a bit smaller than the mean which is about 75000. Notice

Re: [vdr] [PATCH] Fix TS buffer thread high CPU usage

2016-03-14 Thread glenvt18
Hi Klaus, I've tested your patch on x86_64 and ARM (I picked the weakest HW I have). I've gathered some statistics: http://pastebin.com/kXEP9Bp7 Notes. A "good" tuner there means the one that returns bigger chunks on average and generally consumes less CPU cycles with a vanilla (not patched)

Re: [vdr] [PATCH] Fix TS buffer thread high CPU usage

2016-03-10 Thread Klaus Schmidinger
On 10.03.2016 02:54, glenvt18 wrote: Hi folks, I've found that with some DVB tuner drivers poll() returns when there are only small (1-3) number of TS packets available to read(). This results in high CPU usage of the TS buffer thread which is busy reading small chunks of data in

[vdr] [PATCH] Fix TS buffer thread high CPU usage

2016-03-09 Thread glenvt18
Hi folks, I've found that with some DVB tuner drivers poll() returns when there are only small (1-3) number of TS packets available to read(). This results in high CPU usage of the TS buffer thread which is busy reading small chunks of data in cTSBuffer::Action(). 2 out of 3 tuners I tested were