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 stupid. 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 do. 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 :-) ) cheers -henrik 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 vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
