Cinergy T2: High system load due to frontend event polling?

[XLION]

Hi,

I've just successfully compiled the kernel module for my new Cinergy T2
DVB-T USB adapter and configured "vlc" to play DVB-T.
It works nicely, though I've noticed very high system load while
receiving the DVB-T stream.

For I've the same behaviour when using "mplayer", I first thought that
this problem is due to the "cinergyT2" kernel module or rather the DVB-T
implementation in the kernel.

Then I recognized that when I directly record the transport stream
to a file using "tzap <channel_name> -o ..." and then play the file
using "mplayer", neither "tzap" nor "mplayer" does show the
"high system load" behaviour.

So I took a look into "modules/access/dvb/linux_dvb.c" and found
a lot of "polling code". Especially the code in "FrontEndPoll()" seemed
to me a likely cause for high cpu usage ...
// at least when also being "polled" frequently.

Just to find out, if I'm close to the point, I inserted a "1ms" delay before
fetching the next event:

--- linux_dvb.c.orig 2006-05-11 23:45:55.000000000 +0200
+++ linux_dvb.c 2006-05-12 00:13:08.000000000 +0200
@@ -267,6 +267,7 @@

for( ;; )
{
+ msleep(1000);
int i_ret = ioctl( p_sys->i_frontend_handle, FE_GET_EVENT, &event );

if( i_ret < 0 )

I've recompiled and installed "libdvb_plugin.so" and .... BINGO!
CPU usage is down from 99% to 35%, the ondemand scheduler
is clocking down the cpu again and -- more important --
system load has almost disappeared, i. e. cpu usage is entirely
in user space.

Of course inserting msleep(1000) shouldn't be the solution.
Maybe using the "poll()" system call as proposed by the
DVB-T API documentation and/or some other clever trick that
I'm to dumb to figure out at the moment would really SOLVE
the problem.

BytTheWay: my system/environmental details:
- vlc-0.8.5 on gentoo linux
- kernel-2.6.16-gentoo-r3 (CONFIG_HZ=1000)

Feedback very much appreciated

-- Axel

Addition:
Insert "msleep(100)" instead of "msleep(1000)".
Otherwise drop outs (tuning?) occur (on weak signals).

Correction:
"mplayer" does NOT produce high system load, but generally requires
more cpu time in user space than "vlc" for doing the same thing.
Nearly forgot one of the reasons why I prefer "vlc" over "mplayer" ...

[Guest]

Hi,

in the meantime I've experimented with the "poll()" system call
and I have found out that there is no actual reason to change the
"vlc linux_dvb" code, i. e. the "select()"-call of the main polling loop
(access.c) should do the job, i. e. call "FrontendPoll", if and only
if there is input available on the frontend device.

So back to to my original "suspicion" ... the kernel driver:
Inspecting the implementation of "cinergyt2_poll()" showed that
(POLLIN | POLLRDNORM | POLLPRI) is returned regardless of
pending events.

This leads to FD_ISSET( p_sys->i_frontend_handle, &fde ) always
returning true and a "high frequency" = "cpu-time consuming"
polling loop.

In the following are two patches: my "experimental poll-patch" for "vlc"
(just for the records...) and my kernel driver patch von "cinergyT2".

I'm still a little suprised that I haven't found anything on the web
about this problem. Maybe because it does only occur when using
non-blocking IO on the frontend device.
Nevertheless I would be glad to hear from someone that has
experienced tha same problem or -- even better -- can confirm
that patching the kernel module solves it.

-- Axel

==============================================

--- linux_dvb.c.orig 2006-05-11 23:45:55.000000000 +0200
+++ linux_dvb.c 2006-05-13 02:08:33.000000000 +0200
@@ -264,15 +264,37 @@
frontend_t * p_frontend = p_sys->p_frontend;
struct dvb_frontend_event event;
fe_status_t i_status, i_diff;
+ struct pollfd pfd[1];
+ int i_ret;

for( ;; )
{
- int i_ret = ioctl( p_sys->i_frontend_handle, FE_GET_EVENT, &event );
+ msg_Dbg( p_access, "FE: polling: timeout=100ms" );
+ pfd[0].fd = p_sys->i_frontend_handle;
+ pfd[0].events = POLLPRI;
+ i_ret = poll(pfd,1,100);
+ msg_Dbg( p_access, "FE: poll returned: %d", i_ret);
+ if ( i_ret == 0 ) {
+ msg_Dbg( p_access, "FE: poll timed out" );
+ return;
+ }
+ if ( i_ret < 0 ) {
+ msg_Err( p_access, "FE: poll error: %s", strerror(errno) );
+ return;
+ }
+ if ( ! (pfd[0].revents & POLLPRI) ) {
+ msg_Dbg( p_access, "FE: poll: not a POLLPRI event" );
+ return;
+ }

+ i_ret = ioctl( p_sys->i_frontend_handle, FE_GET_EVENT, &event );
+ msg_Dbg( p_access, "FE: ioctl returned: %d", i_ret );
if( i_ret < 0 )
{
- if( errno == EWOULDBLOCK )
+ if ( errno == EWOULDBLOCK ) {
+ msg_Dbg( p_access, "FE: ioctl: EWOULDBLOCK" );
return; /* no more events */
+ }

msg_Err( p_access, "reading frontend event failed (%d) %s",
i_ret, strerror(errno) );

==============================================

--- cinergyT2.c.orig 2006-03-20 06:53:29.000000000 +0100
+++ cinergyT2.c 2006-05-13 01:15:24.000000000 +0200
@@ -540,15 +540,18 @@
{
struct dvb_device *dvbdev = file->private_data;
struct cinergyt2 *cinergyt2 = dvbdev->priv;
+ unsigned int mask = 0;

if (cinergyt2->disconnect_pending || down_interruptible(&cinergyt2->sem))
return -ERESTARTSYS;

poll_wait(file, &cinergyt2->poll_wq, wait);

+ if (cinergyt2->pending_fe_events != 0) mask |= (POLLIN | POLLRDNORM | POLLPRI);
+
up(&cinergyt2->sem);

- return (POLLIN | POLLRDNORM | POLLPRI);
+ return mask;
}

[XLION]

... is there anybody around who is using the same configuration?

If so, have you encountered the same problem (high system load)
or does this -- for some strange reasons -- only occur on my
system???

Cheers,
Axel

[elelelle]

I have the same high CPU-load problem with my Cinergy T2. Tune in a DVB channel with VLC and CPU load goes to almost 100%. Also CPU frequency scaling with cpufreq-selector has no effect and the load stays the same despite CPU frequency.

What is strange is that I'm not experiencing this problem with mplayer or gxine. Both of them give CPU load of about 20% or even lower when using NVidia xxmc... so it definitely seems like a VLC problem.

Btw. I'm using AMD64 version of Ubuntu Dapper. My VLC is the one from the Ubuntu repository, version 0.8.4.debian-1ubuntu6.

[XLION]

As I've figured out, the problem is definitely in the driver,
i. e. in the implementation of the "poll()" system call.

The reason why this does not happen when using xine/mplayer
is propably that both are either not using non-blocking IO on
the frontend device or are not (frequently) polling/selecting
the frontend device, after a channel was locked.
... but I haven't inspected the xine/mplayer dvb code yet.

VLC's -- in my option both smart and correct -- approach to
"select()" the file descriptors of interest in a "big main loop"
while streaming the mpeg data, is affected by this bug,
because "select()" constantly returns the frontend's fd
as "having data available to be read". And this results in
more or less 100% CPU (system) load.

As I've pointed out, applying the patch for the cinergyT2 kernel driver,
fixes the problem for me.

ByTheWay: I've posted the patch (and a modified version that
can be applied to latest v4l-dvb developer sources) to the
"linux-dvb" mailing list at "linuxtv.org" without getting much
feedback, though.

Anyway, good to know that I'm not the only one having this
problem ...

Axel
[/quote]

[elelelle]

Looks like you're right!

I applied your Cinergy T2 kernel driver patch to a vanilla 2.6.16.19 kernel and it works like charm. CPU usage is now comparable to xine and mplayer and staying around 20%. Very nice work and and thanks for figuring this out. I've been totally puzzled over this problem for months.. and yes, blaiming VLC - shame on me.

I sure hope this patch gets included to the v4l-dvb sources soon!

[XLION]

Hi,

the patch finally made it into the "v4l-dvb MASTER repository" on "linuxtv.org".
Still some more hops (v4l-dvb git, ..., linus' git) to go, but it's on its way into a future kernel releases ...

Axel