On Wed, Mar 18, 2009 at 02:40:38PM +0200, Antti Palosaari wrote:
> Heinrich Langos wrote:
>> I ran "dvbtraffic" (itself causing about 10 wakups but hardly any cpu load)
>> on another console to see what is happening and it seems like "femon" 
>> does only check the receiver's status while "zap" realy causes data to 
>> be transfered from the USB device to the host.
> yes. femon only reads demodulator status and zap starts transfer.
>> So the rather heavy load that I see with vdr is probably not caused by vdr
>> itself but by the USB data transfer. 
>> The new questions are:
>> Does every USB DVB-T receiver cause the same amount of cpu load?
> Not sure. This device uses USB bulk transfer with packet size 512. This  
> is most typical packet size and protocol, very many devices are using  
> just same. Some devices are using different packet size.
> There is also isochronous transfer used instead bulk, but it is not very  
> very common. I have no idea how much load it generates.
> I doubt all USB-transfers will generate almost same load when  
> transferring same amount of data. In my understanding USB does not use  
> DMA and that's why it generates high load?

DMA is only possible between memory and the USb host controller. The USB
device is always polled for data. Even the so called interupt transfer mode
is nothing but a high frequency polling mode... well USB sucks compared to
firewise but than again, usb devices are cheap as chips because they can be

I ran a couple of tests with a different DVB-T USB stick. The rather old
"Fujitsu-Siemens DVB-T Mobile TV". That one turns out to need a lot less
system resources. It also transfers the whole transport stream (several
video and audio streams) over the USB and leaves demuxing to the host. 
So we are not comparing apples and oranges.
Comparing those numbers seems to indicate that there is room for improvment
for the af9015 driver. 

I'll try to get my hands on a couple more different usb receivers to try out
some of the other drivers.

What I also found rather scary was the 200 wakups per second that vdr did
even when there is no dvb device to read from. So I removed all vdr plugins
and started adding them one by one.

epgsearch - no problem
live      - no problem
streamdev-server - no problem
ffnetdev  - BINGO

Which makes sense when considering that ffnetdev tries to implement a full
featured card in software. I just didn't know they also try to implement an
INPUT device!

With the usb device enabled, I get various degrees of CPU load, depending on
the plugins installed, but in general the number of wakeups per second is
constant at about 200 per second. Even without any plugin and with noting to

In other words: vdr is polling its input devices at 200 Hertz even when is is
completely idle! I wonder if that is realy necessary... Some vdr guru willing 
to enlighten me? (I'm willing to dodge the stones thrown at the heretic :-) )


PS: I am willing to take the whole driver thread off-list if somebody feels
that this is not the proper list for it, but I think the way vdr behaves
when it is idle is interesting to more people.

vdr mailing list

Reply via email to