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
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
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
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)
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
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