Re: [vdr] power consumption, powertop and wakups per second with a af9015 device, vp7045, and various plugins
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.
Hi!
Heinrich Langos schrieb:
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.
I borrowed an af9015 device some time ago, and the owner told me that the primary problem with it is that it has no hardware PID filter. So even if VDR is only doing EPG scanning, the complete multiplex is congesting the USB link. Maybe your Fujitsu-Siemens receiver has a hardware PID filter...
Ciao
Martin
On Sun, Mar 22, 2009 at 06:16:29PM +0100, Martin Emrich wrote:
Heinrich Langos schrieb:
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.
I borrowed an af9015 device some time ago, and the owner told me that the primary problem with it is that it has no hardware PID filter. So even if VDR is only doing EPG scanning, the complete multiplex is congesting the USB link. Maybe your Fujitsu-Siemens receiver has a hardware PID filter...
Hi Martin,
I am pretty sure the Siemens stick doesn't filter PIDs. The easy way to find out about that is to look at http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices and check if the device works with usb 1.1 or absolutely needs 2.0.
Also the system load doesn't seem to differ a lot between vdr being mostly idle and recording.
I'll get my hands onto a "Toshiba USB DVB-T Tuner PX1211E-1TVD" this week. That one should have a pid filter as it seems to support USB 1.1 as well as 2.0.
cheers -henrik
Hi!
Heinrich Langos schrieb:
I am pretty sure the Siemens stick doesn't filter PIDs. The easy way to find out about that is to look at http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices and check if the device works with usb 1.1 or absolutely needs 2.0.
Hmm, I did't look at this page before. One more curious thing about my af9015 USB device is that it seems to support USB 1.1 under Windows with a special driver:
http://www.digittrade.de/shop/shop_content.php/coID/9
So I think it's just a question of the right firmware; the linux driver does not support hardware PID filters (the driver says something like "Found device in WARM state, disabling PID filter").
Ciao
Martin
On Mon, Mar 23, 2009 at 09:18:56AM +0100, Martin Emrich wrote:
Heinrich Langos schrieb:
I am pretty sure the Siemens stick doesn't filter PIDs. The easy way to find out about that is to look at http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices and check if the device works with usb 1.1 or absolutely needs 2.0.
Hmm, I did't look at this page before. One more curious thing about my af9015 USB device is that it seems to support USB 1.1 under Windows with a special driver:
Interesting. May be worth reverse engineering. Does anybody know if running windows in a virtualbox with USB pass-through allow to sniff the usb traffic?
BTW: I didn't know that there was a manufacturer who made Linux support such a prominent feature. Nice!
So I think it's just a question of the right firmware; the linux driver does not support hardware PID filters (the driver says something like "Found device in WARM state, disabling PID filter").
Mine says:
[27648.472519] dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in cold state, will try to load a firmware [27648.472598] firmware: requesting dvb-usb-af9015.fw [27648.500072] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' [27648.567057] dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in warm state. [27648.567182] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. ...
I don't know if it is just a question of the firmware, or if different sticks with the AF9015 come with support circuitry that may or may not support PID filtering.
@Antti: Do you know?
Cheers -henrik
Heinrich Langos wrote:
On Mon, Mar 23, 2009 at 09:18:56AM +0100, Martin Emrich wrote:
af9015 USB device is that it seems to support USB 1.1 under Windows with a special driver:
I think all (in recent 2 year or so) Windows drivers will support USB1.1. Windows driver is provided by Afatech, device manufacturers only adds correct USB IDs and IR-table for remote they are using. You can download this WHQL-driver from Afatech www-site and use it instead.
Interesting. May be worth reverse engineering. Does anybody know if running windows in a virtualbox with USB pass-through allow to sniff the usb traffic?
I think yes. Usually we use SniffUsb2.0 sniffer in real Windows box or virtual box using Vmware (supports USB2.0).
BTW: I didn't know that there was a manufacturer who made Linux support such a prominent feature. Nice!
So I think it's just a question of the right firmware; the linux driver does not support hardware PID filters (the driver says something like "Found device in WARM state, disabling PID filter").
Linux driver supports PID-filtering (USB1.1). There is no any check in driver against firmware version used, PID-filter should be available always. For dual tuner devices there is no PID-filter for 2nd tuner and driver will disable 2nd tuner in that case if only USB1.1 port is available.
Mine says:
[27648.472519] dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in cold state, will try to load a firmware [27648.472598] firmware: requesting dvb-usb-af9015.fw [27648.500072] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' [27648.567057] dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in warm state. [27648.567182] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. ...
I don't know if it is just a question of the firmware, or if different sticks with the AF9015 come with support circuitry that may or may not support PID filtering.
@Antti: Do you know?
All AF9015 devices supports PID-filtering by HW. And both Windows and Linux driver supports also.
regards Antti
Hi!
Antti Palosaari schrieb:
All AF9015 devices supports PID-filtering by HW. And both Windows and Linux driver supports also.
Interesting. How do I enable the HW PID filter? I have an old STB (Cyrix MediaGX 300MHz) that has only USB 1.1.
Thanks
Martin
moi!
Martin Emrich wrote:
Hi!
Antti Palosaari schrieb:
All AF9015 devices supports PID-filtering by HW. And both Windows and Linux driver supports also.
Interesting. How do I enable the HW PID filter? I have an old STB (Cyrix MediaGX 300MHz) that has only USB 1.1.
Just plug stick to the USB1.1 port and it will be enabled automatically (unless you use very old version of the driver). I want to see message.log entries in error case.
regards Antti
On Mon, Mar 23, 2009 at 01:43:50PM +0200, Antti Palosaari wrote:
moi!
Martin Emrich wrote:
Hi!
Antti Palosaari schrieb:
All AF9015 devices supports PID-filtering by HW. And both Windows and Linux driver supports also.
Interesting. How do I enable the HW PID filter? I have an old STB (Cyrix MediaGX 300MHz) that has only USB 1.1.
Great news indeed. I have some old 233Mhz Geode systems with two 100mBit ethernet and two USB1.1 ports. I used one of those as samba server (and mp3 player via usb soundcard) before swithing to my current old-notebook-hidden-on-top-shelf setup.
Just plug stick to the USB1.1 port and it will be enabled automatically (unless you use very old version of the driver). I want to see message.log entries in error case.
How about a module option to force usage of the PID filter? Should be easy to add if the code for enabling it on demand is aready there.
cheers -henrik
Heinrich Langos wrote:
How about a module option to force usage of the PID filter? Should be easy to add if the code for enabling it on demand is aready there.
It is there. modinfo dvb-usb
Antti
Antti Palosaari schrieb:
Heinrich Langos wrote:
How about a module option to force usage of the PID filter? Should be easy to add if the code for enabling it on demand is aready there.
It is there. modinfo dvb-usb
D'Oh, I only looked at 'modinfo dvb-usb-af9015' :)
Thanks!
Martin
On Mon, Mar 23, 2009 at 05:02:54PM +0200, Antti Palosaari wrote:
Heinrich Langos wrote:
How about a module option to force usage of the PID filter? Should be easy to add if the code for enabling it on demand is aready there.
It is there. modinfo dvb-usb
Wow!
I tried it and using the pid filter greatly reduces system load!
In short it cuts minimal system load for transfeing a tv program from 30% to 1.3% !!! (Yes, I think this deserves three exclamation marks.)
with vdr it reduces the idle load from 37% to 19% (and yes, i waited about a minute after starting vdr to let it settle)
below are some cut'n paste numbers from powertop for the curious.
now, are there any negative side effects to enabling the pid filter that one has to expect?
is it still possible to record two stations that are send over the same OTA channel?
if yes, can reprogramming of the pid filter cause lost packages for a already running recording?
cheers -henrik
More details: i ran zap and vdr on a system that is idle and without either does about 5 wakups per second. polling of the remote is disabled. vdr is the one from e-tobi.net/vdr-experimental lenny vdr-extensions here's the list of plugins that were enabled during the test: | Searching for plugins (VDR 1.6.0-2/1.6.0) (cache hit): epgsearch quickepgsearch conflictcheckonly live epgsearchonly ffnetdev streamdev-server.
##################################################### ==================== remote disabled, pid filter disabled ------------------ running zap
PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies) C0 (cpu running) (30.2%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C2 0.4ms (49.7%) 188 Mhz 100.0% C3 0.1ms (20.1%)
Wakeups-from-idle per second : 3205.5 interval: 10.0s no ACPI power usage estimate available
Top causes for wakeups: 59.6% (4761.9) USB device 5-1 : DVB-T 2 (Afatech) 40.2% (3206.1) <interrupt> : uhci_hcd:usb1, ehci_hcd:usb5, HDA Intel 0.1% ( 5.7) zap : schedule_timeout (process_timeout) 0.0% ( 2.0) xfsaild : schedule_timeout (process_timeout) 0.0% ( 1.8) xfsbufd : schedule_timeout (process_timeout)
------------------- running vdr
PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies) C0 (cpu running) (37.0%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C2 0.4ms (21.2%) 188 Mhz 100.0% C3 0.2ms (41.8%)
Wakeups-from-idle per second : 2507.8 interval: 10.0s no ACPI power usage estimate available
Top causes for wakeups: 58.9% (4300.1) USB device 5-1 : DVB-T 2 (Afatech) 37.6% (2744.9) <interrupt> : uhci_hcd:usb1, ehci_hcd:usb5, HDA Intel 3.0% (220.7) vdr : futex_wait (hrtimer_wakeup) 0.2% ( 12.9) <interrupt> : rtc0 0.1% ( 6.0) vdr : schedule_timeout (process_timeout) 0.1% ( 5.3) vdr : hrtick_set (hrtick) 0.0% ( 2.0) xfsaild : schedule_timeout (process_timeout) 0.0% ( 1.6) xfsbufd : schedule_timeout (process_timeout)
#######################################
------------------ remote disabled, pid filter enabled: ------------------ running zap
PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies) C0 (cpu running) ( 1.1%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C2 0.0ms ( 0.0%) 188 Mhz 100.0% C3 10.6ms (98.9%)
Wakeups-from-idle per second : 96.2 interval: 15.0s no ACPI power usage estimate available
Top causes for wakeups: 50.3% ( 72.9) <interrupt> : uhci_hcd:usb1, ehci_hcd:usb5, HDA Intel 34.3% ( 49.7) USB device 5-1 : DVB-T 2 (Afatech) 5.7% ( 8.2) <kernel core> : ehci_work (ehci_watchdog) 3.8% ( 5.5) zap : schedule_timeout (process_timeout) 1.4% ( 2.0) xfsaild : schedule_timeout (process_timeout) 1.1% ( 1.6) xfsbufd : schedule_timeout (process_timeout)
------------------ running vdr
PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies) C0 (cpu running) (18.7%) 750 Mhz 0.0% polling 0.1ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C2 0.1ms ( 0.3%) 188 Mhz 100.0% C3 0.8ms (81.0%)
Wakeups-from-idle per second : 1044.2 interval: 10.0s no ACPI power usage estimate available
Top causes for wakeups: 49.4% (1137.5) USB device 5-1 : DVB-T 2 (Afatech) 40.1% (922.4) <interrupt> : uhci_hcd:usb1, ehci_hcd:usb5, HDA Intel 9.6% (220.8) vdr : futex_wait (hrtimer_wakeup) 0.3% ( 6.2) vdr : schedule_timeout (process_timeout) 0.2% ( 5.6) <kernel core> : ehci_work (ehci_watchdog) 0.1% ( 2.0) xfsaild : schedule_timeout (process_timeout) 0.1% ( 1.6) xfsbufd : schedule_timeout (process_timeout) 0.0% ( 1.0) vdr : do_nanosleep (hrtimer_wakeup)
#########################################
For completeness and comparability:
The Fujitsu Stick (vp7045) still by far beats the af9015 in terms of resource usage with vdr. (13% vs 19% with or 37% without hw pid filter)
It doesn't seem to hava a hw pid filter ( at least it doesn't react to the force_pid_filter_usage option. so here are the results with the same setup, using the same channels and the same vdr plugins:
--------------------------- without remote, without pid filter ------------------ zap PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies) C0 (cpu running) ( 5.7%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C2 0.0ms ( 0.0%) 188 Mhz 100.0% C3 2.0ms (94.3%)
Wakeups-from-idle per second : 473.5 interval: 10.0s no ACPI power usage estimate available
Top causes for wakeups: 55.7% (592.2) USB device 5-1 : DVB-T 2 (Afatech) 42.9% (455.9) <interrupt> : uhci_hcd:usb1, ehci_hcd:usb5, HDA Intel 0.5% ( 5.7) zap : schedule_timeout (process_timeout) 0.2% ( 2.4) kdvb-ad-0-fe-0 : schedule_timeout (process_timeout) 0.2% ( 2.0) xfsaild : schedule_timeout (process_timeout) 0.2% ( 1.6) xfsbufd : schedule_timeout (process_timeout) 0.1% ( 1.0) zap : do_nanosleep (hrtimer_wakeup)
-------------------- vdr PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies) C0 (cpu running) (13.0%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C2 0.1ms ( 0.1%) 188 Mhz 100.0% C3 1.5ms (86.8%)
Wakeups-from-idle per second : 611.1 interval: 10.0s no ACPI power usage estimate available
Top causes for wakeups: 45.1% (540.5) USB device 5-1 : DVB-T 2 (Afatech) 34.9% (418.2) <interrupt> : uhci_hcd:usb1, ehci_hcd:usb5, HDA Intel 18.4% (220.8) vdr : futex_wait (hrtimer_wakeup)
--------------------------
Heinrich Langos wrote:
For completeness and comparability:
The Fujitsu Stick (vp7045) still by far beats the af9015 in terms of resource usage with vdr. (13% vs 19% with or 37% without hw pid filter)
It doesn't seem to hava a hw pid filter ( at least it doesn't react to the force_pid_filter_usage option. so here are the results with the same setup, using the same channels and the same vdr plugins:
vp7045 does not have PID-filters. I think difference comes from different USB-transfer settings. vp7045 uses BULK packet size 4096 and af9015 uses BULK packet size 512 for USB2.0 and BULK packet size 64 for USB1.1. Therefore af9015 sends 8 times more packets than vp7045 (I guess).
One thing more you can test - use USB1.1. To force USB1.1 remove USB2.0 driver by rmmod ehci_hcd. After that plug af9015 stick and look from logs it detects USB1.1 and uses PID-filters. af9015 driver now uses smaller packet size for transfer that can change load (bigger?).
regards Antti
Moikka Antti,
vp7045 does not have PID-filters. I think difference comes from different USB-transfer settings. vp7045 uses BULK packet size 4096 and af9015 uses BULK packet size 512 for USB2.0 and BULK packet size 64 for USB1.1. Therefore af9015 sends 8 times more packets than vp7045 (I guess).
One thing more you can test - use USB1.1. To force USB1.1 remove USB2.0 driver by rmmod ehci_hcd. After that plug af9015 stick and look from logs it detects USB1.1 and uses PID-filters. af9015 driver now uses smaller packet size for transfer that can change load (bigger?).
without ehci_usb i get this on loading af9015-dvb-usb :
[211324.238031] ehci_hcd 0000:00:1d.7: remove, state 1 [211324.238227] usb usb5: USB disconnect, address 1 [211324.238340] usb 5-1: USB disconnect, address 7 [211324.245523] ehci_hcd 0000:00:1d.7: USB bus 5 deregistered [211324.245837] ACPI: PCI interrupt for device 0000:00:1d.7 disabled [211324.524157] usb 1-1: new full speed USB device using uhci_hcd and address 4 [211324.702426] usb 1-1: configuration #1 chosen from 1 choice [211324.708807] usb 1-1: New USB device found, idVendor=15a4, idProduct=9016 [211324.708965] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [211324.709152] usb 1-1: Product: DVB-T 2 [211324.709275] usb 1-1: Manufacturer: Afatech [211324.709381] usb 1-1: SerialNumber: 010101010600001 [211325.692779] dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in warm state. [211325.692779] dvb-usb: will use the device's hardware PID filter (table count: 32). [211325.697043] DVB: registering new adapter (Afatech AF9015 DVB-T USB2.0 stick) [211326.428116] af9013: firmware version:4.95.0 [211326.448011] DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... [211326.448011] tda18271 0-00c0: creating new instance [211326.455236] TDA18271HD/C2 detected @ 0-00c0 [211326.890065] dvb-usb: Afatech AF9015 DVB-T USB2.0 stick successfully initialized and connected. [211326.933817] usbcore: registered new interface driver dvb_usb_af9015
loading the module seems to cause polling each 250ms: ===================================== PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies) C0 (cpu running) ( 0.2%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C2 0.0ms ( 0.0%) 188 Mhz 100.0% C3 118.1ms (99.8%)
Wakeups-from-idle per second : 8.4 interval: 20.0s no ACPI power usage estimate available
Top causes for wakeups: 37.0% ( 4.0) <kernel module> : usb_hcd_poll_rh_status (rh_timer_func) 18.5% ( 2.0) xfsaild : schedule_timeout (process_timeout) 15.7% ( 1.7) xfsbufd : schedule_timeout (process_timeout) 9.3% ( 1.0) ifconfig : b44_open (b44_timer) ====================================
running zap causes a load between 1.0 and 1.4%
==================================== running zap PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies) C0 (cpu running) ( 1.0%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C2 0.1ms ( 0.0%) 188 Mhz 100.0% C3 14.5ms (99.0%)
Wakeups-from-idle per second : 68.5 interval: 15.0s no ACPI power usage estimate available
Top causes for wakeups: 55.5% ( 84.6) USB device 1-1 : DVB-T 2 (Afatech) 32.3% ( 49.2) <interrupt> : uhci_hcd:usb1, HDA Intel 3.6% ( 5.5) zap : schedule_timeout (process_timeout) 2.7% ( 4.1) <kernel module> : usb_hcd_poll_rh_status (rh_timer_func) 1.3% ( 2.0) xfsaild : schedule_timeout (process_timeout) 1.1% ( 1.7) xfsbufd : schedule_timeout (process_timeout) 0.7% ( 1.1) kdvb-ad-0-fe-0 : schedule_timeout (process_timeout) 0.7% ( 1.0) zap : do_nanosleep (hrtimer_wakeup) ==========================================
and here's the load with idle vdr.
======================================== running vdr PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies) C0 (cpu running) (32.2%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C2 0.1ms ( 0.3%) 188 Mhz 100.0% C3 0.7ms (67.6%)
Wakeups-from-idle per second : 1000.6 interval: 10.0s no ACPI power usage estimate available
Top causes for wakeups: 86.4% (7942.8) USB device 1-1 : DVB-T 2 (Afatech) 10.9% (999.8) <interrupt> : uhci_hcd:usb1, HDA Intel 2.4% (218.0) vdr : futex_wait (hrtimer_wakeup) 0.1% ( 6.4) <interrupt> : ide0 0.1% ( 6.3) vdr : schedule_timeout (process_timeout) 0.0% ( 4.0) <kernel module> : usb_hcd_poll_rh_status (rh_timer_func) 0.0% ( 2.4) vdr : hrtick_set (hrtick) 0.0% ( 2.0) xfsaild : schedule_timeout (process_timeout) 0.0% ( 1.8) xfsbufd : schedule_timeout (process_timeout) ===================================
seems you are right. The transfer with PID filter in usb 1.1 causes about 30% load in contrast to 19% with usb 2.0
is there a way to increase the packet size for those bulk transfers? for usb 2.0? for 1.1?
cheers -henrik
Heinrich Langos wrote:
Moikka Antti,
vp7045 does not have PID-filters. I think difference comes from different USB-transfer settings. vp7045 uses BULK packet size 4096 and af9015 uses BULK packet size 512 for USB2.0 and BULK packet size 64 for USB1.1. Therefore af9015 sends 8 times more packets than vp7045 (I guess).
One thing more you can test - use USB1.1. To force USB1.1 remove USB2.0 driver by rmmod ehci_hcd. After that plug af9015 stick and look from logs it detects USB1.1 and uses PID-filters. af9015 driver now uses smaller packet size for transfer that can change load (bigger?).
seems you are right. The transfer with PID filter in usb 1.1 causes about 30% load in contrast to 19% with usb 2.0
is there a way to increase the packet size for those bulk transfers? for usb 2.0? for 1.1?
Actually AF9015 chip offers registers to configure packet size. But those which are now used are default ones and rather many devices (other than af9015) are using just same. That's why I am not sure if I want change those to bigger ones.
I will make test version that uses 4k packets for your tests. If it resolves problem then we should consider for example adding module param for setting desirable packet size. I will inform you when test version is ready - It takes day or two.
regards Antti
Antti Palosaari wrote:
Heinrich Langos wrote:
Moikka Antti,
vp7045 does not have PID-filters. I think difference comes from different USB-transfer settings. vp7045 uses BULK packet size 4096 and af9015 uses BULK packet size 512 for USB2.0 and BULK packet size 64 for USB1.1. Therefore af9015 sends 8 times more packets than vp7045 (I guess).
One thing more you can test - use USB1.1. To force USB1.1 remove USB2.0 driver by rmmod ehci_hcd. After that plug af9015 stick and look from logs it detects USB1.1 and uses PID-filters. af9015 driver now uses smaller packet size for transfer that can change load (bigger?).
seems you are right. The transfer with PID filter in usb 1.1 causes about 30% load in contrast to 19% with usb 2.0
is there a way to increase the packet size for those bulk transfers? for usb 2.0? for 1.1?
Actually AF9015 chip offers registers to configure packet size. But those which are now used are default ones and rather many devices (other than af9015) are using just same. That's why I am not sure if I want change those to bigger ones.
I will make test version that uses 4k packets for your tests. If it resolves problem then we should consider for example adding module param for setting desirable packet size. I will inform you when test version is ready - It takes day or two.
Unfortunately 512 seems to be biggest allowed packet size so I cannot increase it. Anyhow, there is other configurable parameter called packet count. I increased that from 348 to 512 but I doubt it does not have any effect. Feel free to test. If it does not change load then I think we cannot do more. Test tree: http://linuxtv.org/hg/~anttip/af9015_powertop/
regards Antti
Hi Antti, On Wed, Mar 25, 2009 at 10:48:01PM +0200, Antti Palosaari wrote:
Antti Palosaari wrote:
Heinrich Langos wrote:
Moikka Antti,
vp7045 does not have PID-filters. I think difference comes from different USB-transfer settings. vp7045 uses BULK packet size 4096 and af9015 uses BULK packet size 512 for USB2.0 and BULK packet size 64 for USB1.1. Therefore af9015 sends 8 times more packets than vp7045 (I guess).
One thing more you can test - use USB1.1. To force USB1.1 remove USB2.0 driver by rmmod ehci_hcd. After that plug af9015 stick and look from logs it detects USB1.1 and uses PID-filters. af9015 driver now uses smaller packet size for transfer that can change load (bigger?).
seems you are right. The transfer with PID filter in usb 1.1 causes about 30% load in contrast to 19% with usb 2.0
is there a way to increase the packet size for those bulk transfers? for usb 2.0? for 1.1?
Actually AF9015 chip offers registers to configure packet size. But those which are now used are default ones and rather many devices (other than af9015) are using just same. That's why I am not sure if I want change those to bigger ones.
I will make test version that uses 4k packets for your tests. If it resolves problem then we should consider for example adding module param for setting desirable packet size. I will inform you when test version is ready - It takes day or two.
Unfortunately 512 seems to be biggest allowed packet size so I cannot increase it. Anyhow, there is other configurable parameter called packet count. I increased that from 348 to 512 but I doubt it does not have any effect. Feel free to test. If it does not change load then I think we cannot do more. Test tree: http://linuxtv.org/hg/~anttip/af9015_powertop/
Thank you very much for your work and helpful information. Sorry it took me some time to fire up that stick again.. here's the result:
In short the improvements (if any) are within the error margin. The snapshots below seem to indicate that load with pid filter is reduced somewhat, but i assure you that you get loads from 1.4-1.0 and 22-16% respectivly. So there seems no gain in changing the packet count constant. As usual I have included the details below.
BTW: I got myself a "Toshiba USB DVB-T Tuner PX1211E-1TVD" based on the DiB3000M-C/P. Unlike the siemens stick it has a pid filter. I only tested it without the pid filter yet, and it seems to perform as good as the siemens stick in terms of system load. So I guess it uses big packets for the bulk transfers.
I hope I'll have some time to test it further this weekend. Hopefully it turns out to reduce the system load by the driver to a reasonable level. If so I will finally get around to look into vdr itself as a cause of wasted CPU cycles and energy... :-)
cheers -henrik
Details:
# modprobe -v dvb_usb_af9015 insmod /lib/modules/2.6.26-1-686/kernel/drivers/media/dvb/dvb-core/dvb-core.ko insmod /lib/modules/2.6.26-1-686/kernel/drivers/media/dvb/dvb-usb/dvb-usb.ko disable_rc_polling=1 insmod /lib/modules/2.6.26-1-686/kernel/drivers/media/dvb/dvb-usb/dvb-usb-af9015.ko # dmesg | tail [421479.228321] af9015: recv bulk message failed:-110 [421481.228225] af9015: recv bulk message failed:-110 [421481.236400] dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in warm state. [421481.236940] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [421481.237973] DVB: registering new adapter (Afatech AF9015 DVB-T USB2.0 stick) [421481.714270] af9013: firmware version:4.95.0 [421481.724131] DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... [421481.724847] tda18271 0-00c0: creating new instance [421481.729438] TDA18271HD/C2 detected @ 0-00c0 [421481.994205] dvb-usb: Afatech AF9015 DVB-T USB2.0 stick successfully initialized and connected. [421482.012365] usbcore: registered new interface driver dvb_usb_af9015 [421992.345780] tda18271: performing RF tracking filter calibration [421997.798964] tda18271: RF tracking filter calibration complete
====================== no pid filter =========================
zap: | PowerTOP version 1.10 (C) 2007 Intel Corporation | | Cn Avg residency P-states (frequencies) | C0 (cpu running) (30.8%) 750 Mhz 0.0% | polling 0.2ms ( 0.0%) 563 Mhz 0.0% | C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% | C2 0.4ms ( 7.3%) 188 Mhz 100.0% | C3 0.2ms (61.9%) | | Wakeups-from-idle per second : 3100.6 interval: 10.0s | no ACPI power usage estimate available | | Top causes for wakeups: | 60.5% (4774.2) USB device 5-1 : DVB-T 2 (Afatech) | 39.3% (3107.5) <interrupt> : uhci_hcd:usb1, HDA Intel, ehci_hcd:usb5 | 0.1% ( 5.7) zap : schedule_timeout (process_timeout) | 0.0% ( 2.0) xfsaild : schedule_timeout (process_timeout) | 0.0% ( 1.6) xfsbufd : schedule_timeout (process_timeout) | 0.0% ( 1.2) syslogd : ehci_irq (ehci_watchdog) | 0.0% ( 1.0) zap : do_nanosleep (hrtimer_wakeup) | 0.0% ( 1.0) ifconfig : b44_open (b44_timer)
vdr: | PowerTOP version 1.10 (C) 2007 Intel Corporation | | Cn Avg residency P-states (frequencies) | C0 (cpu running) (34.6%) 750 Mhz 0.0% | polling 0.0ms ( 0.0%) 563 Mhz 0.0% | C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% | C2 0.1ms ( 0.5%) 188 Mhz 100.0% | C3 0.3ms (64.9%) | | Wakeups-from-idle per second : 2588.7 interval: 10.0s | no ACPI power usage estimate available | | Top causes for wakeups: | 59.3% (4318.9) USB device 5-1 : DVB-T 2 (Afatech) | 37.5% (2730.5) <interrupt> : uhci_hcd:usb1, HDA Intel, ehci_hcd:usb5 | 3.0% (220.9) vdr : futex_wait (hrtimer_wakeup) | 0.1% ( 6.2) vdr : schedule_timeout (process_timeout) | 0.0% ( 2.0) xfsaild : schedule_timeout (process_timeout) | 0.0% ( 1.6) xfsbufd : schedule_timeout (process_timeout) | 0.0% ( 1.3) syslogd : ehci_irq (ehci_watchdog) | 0.0% ( 1.1) vdr : hrtick_set (hrtick) | 0.0% ( 1.0) vdr : do_nanosleep (hrtimer_wakeup) | 0.0% ( 1.0) ifconfig : b44_open (b44_timer)
====================== with hw pid filter =========================
# modprobe -v dvb-usb force_pid_filter_usage=1 insmod /lib/modules/2.6.26-1-686/kernel/drivers/media/dvb/dvb-core/dvb-core.ko insmod /lib/modules/2.6.26-1-686/kernel/drivers/media/dvb/dvb-usb/dvb-usb.ko force_pid_filter_usage=1 disable_rc_polling=1 # modprobe -v dvb_usb_af9015 insmod /lib/modules/2.6.26-1-686/kernel/drivers/media/dvb/dvb-usb/dvb-usb-af9015.ko
zap: | PowerTOP version 1.10 (C) 2007 Intel Corporation | | Cn Avg residency P-states (frequencies) | C0 (cpu running) ( 1.1%) 750 Mhz 0.0% | polling 0.0ms ( 0.0%) 563 Mhz 0.0% | C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% | C2 0.0ms ( 0.0%) 188 Mhz 100.0% | C3 10.6ms (98.9%) | | Wakeups-from-idle per second : 95.7 interval: 15.0s | no ACPI power usage estimate available | | Top causes for wakeups: | 48.8% ( 70.1) <interrupt> : uhci_hcd:usb1, HDA Intel, ehci_hcd:usb5 | 33.2% ( 47.7) USB device 5-1 : DVB-T 2 (Afatech) | 7.0% ( 10.1) syslogd : ehci_irq (ehci_watchdog) | 4.7% ( 6.8) zap : schedule_timeout (process_timeout) | 1.4% ( 2.0) xfsaild : schedule_timeout (process_timeout) | 1.2% ( 1.7) xfsbufd : schedule_timeout (process_timeout) | 0.7% ( 1.1) kdvb-ad-0-fe-0 : schedule_timeout (process_timeout) | 0.7% ( 1.0) ifconfig : b44_open (b44_timer) | 0.7% ( 1.0) zap : do_nanosleep (hrtimer_wakeup)
vdr: | PowerTOP version 1.10 (C) 2007 Intel Corporation | | Cn Avg residency P-states (frequencies) | C0 (cpu running) (16.8%) 750 Mhz 0.0% | polling 0.1ms ( 0.0%) 563 Mhz 0.0% | C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% | C2 0.1ms ( 0.3%) 188 Mhz 100.0% | C3 0.9ms (82.9%) | | Wakeups-from-idle per second : 938.4 interval: 10.0s | no ACPI power usage estimate available | | Top causes for wakeups: | 48.6% (988.7) USB device 5-1 : DVB-T 2 (Afatech) | 39.5% (804.2) <interrupt> : uhci_hcd:usb1, HDA Intel, ehci_hcd:usb5 | 10.9% (221.1) vdr : futex_wait (hrtimer_wakeup) | 0.3% ( 6.9) syslogd : ehci_irq (ehci_watchdog) | 0.3% ( 6.0) vdr : schedule_timeout (process_timeout) | 0.1% ( 2.0) xfsaild : schedule_timeout (process_timeout) | 0.1% ( 1.6) xfsbufd : schedule_timeout (process_timeout) | 0.0% ( 1.0) ifconfig : b44_open (b44_timer) | 0.0% ( 1.0) vdr : do_nanosleep (hrtimer_wakeup)
Heinrich Langos wrote:
BTW: I got myself a "Toshiba USB DVB-T Tuner PX1211E-1TVD" based on the DiB3000M-C/P. Unlike the siemens stick it has a pid filter. I only tested it without the pid filter yet, and it seems to perform as good as the siemens stick in terms of system load. So I guess it uses big packets for the bulk transfers.
I didn't find that stick from code. I assume it is "LITE-ON USB2.0 DVB-T Tuner" which is sold rebranded as Toshiba (according to one comment in code). If same device then it does have PID filter and uses 4096 BULK packets.
I hope I'll have some time to test it further this weekend. Hopefully it turns out to reduce the system load by the driver to a reasonable level. If so I will finally get around to look into vdr itself as a cause of wasted CPU cycles and energy... :-)
I have very many devices but haven't tested loads yet.
regards Antti
On Fri, Mar 27, 2009 at 12:57:14PM +0200, Antti Palosaari wrote:
Heinrich Langos wrote:
BTW: I got myself a "Toshiba USB DVB-T Tuner PX1211E-1TVD" based on the DiB3000M-C/P. Unlike the siemens stick it has a pid filter. I only tested it without the pid filter yet, and it seems to perform as good as the siemens stick in terms of system load. So I guess it uses big packets for the bulk transfers.
I didn't find that stick from code. I assume it is "LITE-ON USB2.0 DVB-T Tuner" which is sold rebranded as Toshiba (according to one comment in code). If same device then it does have PID filter and uses 4096 BULK packets.
Yeap, thats the one ... see http://www.linuxtv.org/wiki/index.php/DVB-T_USB_Devices
[329345.857835] dvb-usb: found a 'LITE-ON USB2.0 DVB-T Tuner' in warm state. [329345.859820] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [329345.862374] DVB: registering new adapter (LITE-ON USB2.0 DVB-T Tuner) [329345.875554] DVB: registering adapter 0 frontend 0 (DiBcom 3000MC/P)... [329345.898401] MT2060: successfully identified (IF1 = 1220) [329346.390290] dvb-usb: LITE-ON USB2.0 DVB-T Tuner successfully initialized and connected. [329346.390729] usbcore: registered new interface driver dvb_usb_dibusb_mc
Kind of frustrating .. from 3 usb dvb-t receivers that i own, not even one is recognized by its real name :-) At least your af9015 driver doesn't pretend to know the brand.
I hope I'll have some time to test it further this weekend. Hopefully it turns out to reduce the system load by the driver to a reasonable level. If so I will finally get around to look into vdr itself as a cause of wasted CPU cycles and energy... :-)
I have very many devices but haven't tested loads yet.
Could be interesting. Especially with the whole IT world moving towards more energy efficient systems ...
Do you think we should start to document the findings in the linuxtv wiki?
BTW: I think we might better take this thread to linix-dvb as is now mostly deals with driver issues and less with vdr. (I would have started it there but I didn't know the source of the system load nor the layout of mailinglists on linuxtv then)
cheers and thank you for your help.
-henrik
Hi Antti,
Just to complete this I've made some tests with the "Toshiba USB DVB-T Tuner PX1211E-1TVD".
The short result is: Without PID filter its load is equivalent to the Fujitsu-Siemens. (5.8% and 14.4%) With PID filter it produces even less load than the af9015 with pid filter. About 0.5% with zap and 9.7% with an idle vdr.
Since managing all those numbers starts to get confusing I've put them together on my page at the linuxtv wiki: http://www.linuxtv.org/wiki/index.php/User:Hlangos
I hope I'll be able to add some more receivers.
cheers -henrik
PS : I'll attach the results of the toshiba stick in order to get it archived with the rest of the thread.
Heinrich Langos wrote:
now, are there any negative side effects to enabling the pid filter that one has to expect?
You cannot receive all channels in the mux at the same time (at least in case there is more than 32 PIDs in the transport stream).
is it still possible to record two stations that are send over the same OTA channel?
I think in theory yes. One program stream is typically less than 5 Mbit/s and USB1.1 can carry around 12Mbit/s. Anyhow, you are now using USB2.0 with PID-filter which means USB can transfer 480 Mbit/s in theory. AF9015 does have 32 PID-filters which sets some limits. 32 is still more than enough for 2 channels....
if yes, can reprogramming of the pid filter cause lost packages for a already running recording?
No.
regards Antti
Here's the powertop output for the siemens stick in various situations:
cheers -henrik
---------------------------- running zap to tune into a channel ---------------------------- and transfer the TS over USB
PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies) C0 (cpu running) ( 5.8%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C2 0.1ms ( 0.0%) 188 Mhz 100.0% C3 1.9ms (94.2%)
Wakeups-from-idle per second : 486.1 interval: 10.0s no ACPI power usage estimate available
Top causes for wakeups: 55.3% (598.2) USB device 5-1 : DVB-T 2 (Afatech) 42.8% (462.3) <interrupt> : uhci_hcd:usb1, ehci_hcd:usb5, HDA Intel 0.5% ( 5.6) zap : schedule_timeout (process_timeout) 0.2% ( 2.3) events/0 : schedule_timeout (process_timeout) 0.2% ( 2.2) khubd : queue_delayed_work (delayed_work_timer_fn) 0.2% ( 2.0) xfsaild : schedule_timeout (process_timeout) 0.2% ( 2.0) kdvb-ad-0-fe-0 : schedule_timeout (process_timeout) 0.2% ( 1.8) xfsbufd : schedule_timeout (process_timeout) 0.1% ( 1.0) zap : do_nanosleep (hrtimer_wakeup) 0.1% ( 1.0) ifconfig : b44_open (b44_timer) 0.0% ( 0.5) <kernel core> : neigh_table_init_no_netlink (neigh_periodic_timer) 0.0% ( 0.5) <kernel core> : schedule_delayed_work_on (delayed_work_timer_fn) 0.0% ( 0.3) <kernel module> : neigh_table_init_no_netlink (neigh_periodic_timer) 0.0% ( 0.2) <interrupt> : uhci_hcd:usb3, eth0 0.0% ( 0.2) init : schedule_timeout (process_timeout) 0.0% ( 0.2) <kernel core> : __netdev_watchdog_up (dev_watchdog) 0.0% ( 0.2) runsvdir : schedule_timeout (process_timeout) 0.0% ( 0.1) screen : do_setitimer (it_real_fn) 0.0% ( 0.1) <kernel module> : <f8b4191b> (inet_frag_secret_rebuild) 0.0% ( 0.1) <kernel core> : addrconf_verify (addrconf_verify) 0.0% ( 0.1) nmbd : schedule_timeout (process_timeout)
Suggestion: Enable USB autosuspend by pressing the U key or adding usbcore.autosuspend=1 to the kernel command line in the grub config
Q - Quit R - Refresh U - Enable USB suspend
-------------------------------------- running vdr and having it idle around. -------------------------------------- i.e. not recording anything
jukebox:/home/data/static# /etc/init.d/vdr start Starting Linux Video Disk Recorder: vdr Searching for plugins (VDR 1.6.0-2/1.6.0) (cache hit): epgsearch femon dvdswitch quickepgsearch conflictcheckonly live epgsearchonly dvd ffnetdev streamdev-server xineliboutput.
PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies) C0 (cpu running) (14.8%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C2 0.1ms ( 0.2%) 188 Mhz 100.0% C3 1.3ms (85.1%)
Wakeups-from-idle per second : 655.9 interval: 10.0s no ACPI power usage estimate available
Top causes for wakeups: 45.8% (606.2) USB device 5-1 : DVB-T 2 (Afatech) 35.6% (470.9) <interrupt> : uhci_hcd:usb1, ehci_hcd:usb5, HDA Intel 16.7% (220.9) vdr : futex_wait (hrtimer_wakeup) 0.7% ( 9.5) vdr : schedule_timeout (process_timeout) 0.2% ( 2.2) khubd : queue_delayed_work (delayed_work_timer_fn) 0.2% ( 2.2) events/0 : schedule_timeout (process_timeout) 0.2% ( 2.0) xfsaild : schedule_timeout (process_timeout) 0.2% ( 2.0) kdvb-ad-0-fe-0 : schedule_timeout (process_timeout) 0.1% ( 1.6) xfsbufd : schedule_timeout (process_timeout) 0.1% ( 1.0) vdr : do_nanosleep (hrtimer_wakeup) 0.1% ( 1.0) ifconfig : b44_open (b44_timer) 0.0% ( 0.5) <kernel core> : neigh_table_init_no_netlink (neigh_periodic_timer) 0.0% ( 0.5) <kernel core> : schedule_delayed_work_on (delayed_work_timer_fn) 0.0% ( 0.3) <kernel module> : neigh_table_init_no_netlink (neigh_periodic_timer) 0.0% ( 0.2) vdr : hrtick_set (hrtick) 0.0% ( 0.2) <kernel core> : __netdev_watchdog_up (dev_watchdog) 0.0% ( 0.2) xfssyncd : schedule_timeout (process_timeout) 0.0% ( 0.2) init : schedule_timeout (process_timeout) 0.0% ( 0.2) runsvdir : schedule_timeout (process_timeout) 0.0% ( 0.2) smbd : schedule_timeout (process_timeout) 0.0% ( 0.1) <kernel core> : neigh_add_timer (neigh_timer_handler)
Suggestion: Enable USB autosuspend by pressing the U key or adding usbcore.autosuspend=1 to the kernel command line in the grub config
----------------------------------------- just for comparison. vdr running without ehci_hcd and uhci_hcd ----------------------------------------- so there is no dvb device to get data from
PowerTOP version 1.10 (C) 2007 Intel Corporation
Cn Avg residency P-states (frequencies) C0 (cpu running) ( 5.3%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C2 0.1ms ( 0.0%) 188 Mhz 100.0% C3 4.6ms (94.7%)
Wakeups-from-idle per second : 206.7 interval: 10.0s no ACPI power usage estimate available
Top causes for wakeups: 92.7% (197.0) vdr : futex_wait (hrtimer_wakeup) 2.8% ( 6.0) vdr : schedule_timeout (process_timeout) 0.9% ( 2.0) xfsaild : schedule_timeout (process_timeout) 0.8% ( 1.6) xfsbufd : schedule_timeout (process_timeout) 0.5% ( 1.0) vdr : do_nanosleep (hrtimer_wakeup) 0.5% ( 1.0) ifconfig : b44_open (b44_timer) 0.3% ( 0.7) <interrupt> : ide0 0.2% ( 0.5) <kernel core> : schedule_delayed_work_on (delayed_work_timer_fn) 0.2% ( 0.5) <kernel core> : neigh_table_init_no_netlink (neigh_periodic_timer) 0.2% ( 0.4) <kernel module> : ide_do_rw_disk (ledtrig_ide_timerfunc) 0.1% ( 0.3) <kernel module> : neigh_table_init_no_netlink (neigh_periodic_timer) 0.1% ( 0.2) <interrupt> : sata_sil24 0.1% ( 0.2) init : schedule_timeout (process_timeout) 0.1% ( 0.2) <kernel core> : __netdev_watchdog_up (dev_watchdog) 0.1% ( 0.2) xfssyncd : schedule_timeout (process_timeout) 0.1% ( 0.2) runsvdir : schedule_timeout (process_timeout) 0.0% ( 0.1) <kernel core> : end_that_request_last (laptop_timer_fn) 0.0% ( 0.1) pdflush : hrtick_set (hrtick) 0.0% ( 0.1) touch : start_this_handle (commit_timeout) 0.0% ( 0.1) nmbd : schedule_timeout (process_timeout) 0.0% ( 0.1) cron : do_nanosleep (hrtimer_wakeup)
-
Antti Palosaari -
Heinrich Langos -
Martin Emrich