LCDproc development and user support list

Text archives Help


[Lcdproc] LCDd 0.5.1 eating almost alll CPU on Debian Etch


Chronological Thread 
  • From: mattia.jona AT gmail.com (Mattia Jona-Lasinio)
  • Subject: [Lcdproc] LCDd 0.5.1 eating almost alll CPU on Debian Etch
  • Date: Tue Feb 27 17:42:01 2007

Hi all,

I'm the maintainer of the LCD-Linux project which is a kernel driver for the
HD44780 controller connected to the parallel port.
I experience the same problem as you report here: programs using
LCD-Linux eat a
lot of cpu time. This happened since I moved to a distribution with a
2.6 Linux
kernel. With the 2.4 kernel the cpu load was almost unreadable.
Therefore I don't think it is a matter of busy waiting loops but rather a
problem of HZ value in the kernel as Stefan suggested. Can someone try
a kernel
compiled with the old 100 Hz value? Most kernels included in distributions
are
compiled with a HZ value of 1000 to take advantage of the new 2.6 Linux
scheduler and to have a finer grained time for processes.
My tests are done on an Athlon 2800+ CPU with 1Gb of RAM. I think this
is quite
a fast machine to handle LCD stuff.

Bye,

Mattia

Quoting Stefan Herdler
<herdler AT gmx.de<https://mail.lens.unifi.it/horde/imp/message.php?index=9#>
:

[Hide Quoted Text]<https://mail.lens.unifi.it/horde/imp/message.php?index=9#>
Hi,
Peter Marschall wrote:
Hi Leandro,

On Saturday, 24. February 2007 15:27, Leandro Dardini wrote:
Hi all,
I am trying to upgrade my set-top-box from Debian-Sarge to Debian-Etch.
Unfortunately the LCDd 0.5.1 process on the new operating system version
seems to get a lots of CPU power, as you can see from the top shown
below. I tried also the 0.5.0 version and it has the same behavior. Any
idea?
Unfortunately you do not give very much information about your setup
(hardware: computer, LCD, software: configuration...) so that it is
very hard to give sensible advice.
I had the same problems while writing the parallel-port-part of the
serialVFD-driver.
The LCDd took about 30% with the Display connected to the parallel-port.
With the same Display connected serial the CPU-load was only 1 to 2%.
It might be that your CPU is so slow and you send so much data to
LCDd that it really needs this much of the CPU.
I don' think so. In my tests the CPU-load caused by the LCDd was not CPU
dependent.
The difference between a PIII 500 and a Athlon 2800 was only minimal.
You may try to compile the latest CVS to see if the problem is fixed there.

When compiling LCDproc from source you may also try to play a bit with the
various DELAY_* defines in server/drivers/timing.h.
Switching to a different delay type might help.
I think that is worth a try. I'm pretty sure the delays are blocking your
CPU.
The first thing to do is to reduce the delays in the LCDd.conf to the
minimum needed by your display.

You can also try to increase the HZ-value of the kernel, that might help
a bit too.
Hope it helps
Peter
Stefan
_______________________________________________
LCDproc mailing list
LCDproc AT lists.omnipotent.net<https://mail.lens.unifi.it/horde/imp/message.php?index=9#>
http://lists.omnipotent.net/mailman/listinfo/lcdproc


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
Hi all,

I'm the maintainer of the LCD-Linux project which is a kernel driver for the
HD44780 controller connected to the parallel port.
I experience the same problem as you report here: programs using
LCD-Linux eat a
lot of cpu time. This happened since I moved to a distribution with a
2.6 Linux
kernel. With the 2.4 kernel the cpu load was almost unreadable.
Therefore I don't think it is a matter of busy waiting loops but rather a
problem of HZ value in the kernel as Stefan suggested. Can someone try
a kernel
compiled with the old 100 Hz value? Most kernels included in distributions are
compiled with a HZ value of 1000 to take advantage of the new 2.6 Linux
scheduler and to have a finer grained time for processes.
My tests are done on an Athlon 2800+ CPU with 1Gb of RAM. I think this
is quite
a fast machine to handle LCD stuff.

Bye,

Mattia

Quoting Stefan Herdler <herdler AT gmx.de>:

Hi,
Peter Marschall wrote:
Hi Leandro,

On Saturday, 24. February 2007 15:27, Leandro Dardini wrote:
Hi all,
I am trying to upgrade my set-top-box from Debian-Sarge to Debian-Etch.
Unfortunately the LCDd 0.5.1 process on the new operating system version
seems to get a lots of CPU power, as you can see from the top shown
below. I tried also the 0.5.0 version and it has the same behavior. Any
idea?
Unfortunately you do not give very much information about your setup
(hardware: computer, LCD, software: configuration...) so that it is
very hard to give sensible advice.
I had the same problems while writing the parallel-port-part of the serialVFD-driver.
The LCDd took about 30% with the Display connected to the parallel-port.
With the same Display connected serial the CPU-load was only 1 to 2%.
It might be that your CPU is so slow and you send so much data to
LCDd that it really needs this much of the CPU.
I don' think so. In my tests the CPU-load caused by the LCDd was not CPU dependent.
The difference between a PIII 500 and a Athlon 2800 was only minimal.
You may try to compile the latest CVS to see if the problem is fixed there.

When compiling LCDproc from source you may also try to play a bit with the
various DELAY_* defines in server/drivers/timing.h.
Switching to a different delay type might help.
I think that is worth a try. I'm pretty sure the delays are blocking your CPU.
The first thing to do is to reduce the delays in the LCDd.conf to the
minimum needed by your display.

You can also try to increase the HZ-value of the kernel, that might help
a bit too.
Hope it helps
Peter
Stefan
_______________________________________________
LCDproc mailing list
LCDproc AT lists.omnipotent.net
http://lists.omnipotent.net/mailman/listinfo/lcdproc


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.


Archive powered by MHonArc 2.6.18.

Top of page