Mark Weaver wrote:
>> lirc_dev has to poll the I2C bus for new IR signals. I'm surprised
>> that the cpu load is that high (if the given number is really
>> accurate is a different story).
>> If you don't like it, then fix it and send patches.
> It sounds like the I2C driver is using i2c-algo-bit. This basically
> drives the I2C clock and data lines itself at the appropriate
> frequency (as set by the I2C adapter, e.g. a TV card driver), and uses
> udelays to wait for clock transitions. Since these are timed busy
> loops, and CPU load is measured over a particular time, it's not
> really a surprise that it takes a constant fraction of CPU time.
> Speeding up the CPU won't help of course -- it will just whizz around
> the busy loop faster.
> For example I have had a Hauppauge PVR-150 in an Athlon 1600+ and a
> Sempron 2800+ box and lirc_i2c takes about 1% of the CPU to poll in
> either of them. The ivtv udelay is 10us, and you get that twice per
> bit. The chip returns 6 bytes of data, so roughly (ignoring the
> details of the I2C protocol), we have 6*20*8 = 960us ~ 1ms of udelay.
> Polling rate is 10Hz, so that makes ~10ms of busy loop per second,
> which is 1%.
thanks, very enlightning answer, really...
has lirc always behaved that way? i just reinstalled my htpc to clean up
the mess of the first approach after nearly 2 years (old had 2.4 kernel,
older ivtv and of course lirc) and the 1% load was something i couldnt
remember from before.
is there a way to get rid of the polling?
i dont want to sound rude, thank you for your work on lirc, it works
great, but that constant load just looks wrong :P
11:33:04 up 11:56, 1 user, load average: 1.00, 1.02, 1.00