[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fedora, usleep and overrun errors.

----- Original Message ----- From: <leif@xxxxxxxxxx> 
To: "Linrad mailinglist" <linrad@xxxxxxxxxxxxxxxxxxxxx>
Sent: Saturday, March 12, 2005 8:20 PM
Subject: Fedora, usleep and overrun errors.


Hi All,

Modern Linux distributions seem to include undesireable
features that are intended for office use but that degrade
the real time performance of Linux.

I have been running Fedora Core 3 for a while and I will
change back to something old and better controllable for
the future. Before that I think I will use Suse for a while
just to get an idea about what shortcomings it may have.


The problem with Fedora seems to be Hal. This daemon is
active on the hard disk every 30 seconds or so. APM is
not supported by the kernel and would probably not work
as I would like it to (low power mode 2 hours after
hard disk unused)

Not having the power saving running is a minor problem and
probably there is a way to make it run under Fedora that I
just do not know about.

Other problems with Fedora3:

If one runs Linrad without using usleep in the idle loop,
Linrad will use up all the CPU time. Hal and other things that
Fedora wants to run will then interrupt Linrad now and then
which should be perfectly OK - but because of the extremely
long latency it does not work. As it turns out, the kernel
allows other processes to take control over the CPU for over
100 milliseconds occasionally and that is far too much.
Overrun errors are generated.

By allowing the idle loop to issue usleep statements now and then,
Linrad gives away some time for other processes and then the
time other processes take control becomes much shorter and
no overrun errors occur.

The use of usleep is set in the "T" function of the main menu
and the recommended setting is to not use it. Some versions
of Linux may wait for much longer than the specified time
before they return to Linrad and then the usage of usleep
will generate overrun errors.


The multi-threaded version of Linrad does not have this problem
at all. There is no idle loop, all the Linrad processes wait
for events and CPU time is given to Hal and other (silly useless)
processes:-)

The multi-threaded version is a little less efficient than the
monolithic version although one should expect the opposite.
Maybe I will find out why some day.....

The multi-threaded version is far from stable and there will
probably be some more versions in the Linrad-01.xx series
before 02-00 is released. Linrad-01.32 with a few bug corrections
was uploaded a few days ago. If Linrad runs without unexpected
stops in the audio output there is no reason to upgrade. The
bugs are related to flags that say buffer full did not become reset
and therefore an eternal wait for buffer space was the consequence.
If you did not see the error your system and parameter combination
did never fill the buffer and no error occured.


73

Leif



#############################################################
This message is sent to you because you are subscribed to
 the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx> 
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>





#############################################################
This message is sent to you because you are subscribed to
 the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>
LINRADDARNIL
l