[linrad] Re: Fedora 3

[<leif@xxxxxxxxxx>]

Hi Chris,

> So the problem is that cron starts of so resource intensive
> processes now and then?  The solution is not to stop cron but
> to change what gets started up by cron.  On a Fedora system,
> in the /etc/ directory are a set of directories like cron.*
> where "*" matches "daily", "hourly", and so on.  inside this
> directoies are scripts that get run daily, hourly, and so on.
> You can add or remove scripts as required or modify the scripts
> to run at low priority with "nice".  Read the "cron" manpage
> for details
Yes, It is surely possible to taylor Fedora 3 to work perfectly
well with Linrad. It does take some knowledge to do that and
newcomers who know nothing in advance will find it confusing.

Everyone who knows a little about Linux should be able to
configure any Linux distribution to work fine with Linrad but
by selecting more stable ones Like RedHat 9 the user can just
use the standard package as it is.

Removing cron.slocate is always a good thing however....

> If you dont run hald then you will not have it's services. this
> means yo will not be able to "hot plug" devices into your system
> and hve then noticed.  
I have been adviced to not remove HAL. It was said to do other
things than monitoring the "hot plugs". Allocating memory
and other essentials.... 

> mlockall works in must cases. A program running as root can
> lock to many pages caussing big problems.  To solutions
> 1) don't run as root then you will get ENOMEM then deal with the
> problem reasonably, like printing a warning "unable to lock"
> 2) use mlock() and lock only what you really need to be locked
Linrad uses mlockall() because only a very small part of the
allocated memory is not needed. Of course some improvement is 
possible because it may be possible that the run time libraries
of C and svgalib use up a lot of memory in a careless way.

The reason for Linrad to use memlock() is to get an error 
code in case it fails. I have had error reports from several
Linrad newcomers who had set parameters to allocate 500
megabytes or more on computers not having as much physical
memory. When part of the Linrad data memory resides on the
hard disk one typically gets overrun errors occasionally.
By use of memlocall() (which has to be disabled under Fedora)
Linrad gets the information it has to change parameters
to make memory requirements fit the available physical
memory. Linrad makes a suggestion and prompts the
user to the parameter select routine.

The simple strategy with memlockall() works under all 
Linux distributions except for Fedora 3 which most certainly 
has a bug. A small program that only calls memlocall()
freezes the computer and there is no other escape than
the mains cable (or a very long press on the reset button)
 
> In an extreme case, I had to fall back tousing "Real Time Linux"
> I needed a process to run a loop at an _exact_ rate, to within 
> a few microseconds for hours on end with no interruption at the
> microsecond level.  I used a modified Linux kernel
> 
> The application was controlling an astronomical camera, moving
> charge around on a CCD by putting voltages on the CCD's pins
> with the correct timming.  This is really the onlyway to go
> if you have a "hard" real time requirement
> 
> Look at this URL
> http://www.realtimelinuxfoundation.org/
> and then look at this "varient" RTLinux
> This has evolved since I used it into this
> http://www.fsmlabs.com/rtlinuxfree.html
> 
> There are other "varients" that may be more sutable

Linrad does not need any of this at all. 
Linrad just needs a standard Linux distribution and a latency
of up to something like 10 milliseconds is perfectly OK.
This is by no means realtime requirements....

The multi-threaded Linrad version does not have any
problem at all because it puts maximum priority to
the critical parts of Linrad and then the things
launched by cron will only use time not needed by
Linrads processing parts. If some screen updates are 
delayed or even lost does not matter because the next
update from memory will be correct on screen anyway.

There is a problem however. I can not use memlockall() 
with the multi-threaded version on my small computers that
really need it because the multi-threaded version allocates
far to much memory that it does not really use. To get
enough memory for the Linrad data arrays on my 200MHz
PentiumI I have to allow all the overhead to be swapped
onto the hard disk. I will have to specify exactly 
what data areas to lock in order to ensure that swapping
does not cause problems in the multi-threaded version.

73

Leif / SM5BSZ





#############################################################
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