Mr. Pfistner,
> What happens whith a rtfifo when a rt-task continiously writes to it
(exceeding its
> size) and noone reads the data out?
From the man page, the rtf_put that would put too much data in the
buffer returns
-ENOSPC. A quick browse of the source code shows that it returns -ENOSPC
without writing anything to the FIFO. In other words, the FIFO is not
changed at all by the rtf_put that would more than fill the FIFO.
> May this effect system stability?
It will not change the stability of RTLinux, though it will probably
cause problems for your software if the non-RT end of the FIFO (assuming
this is an RT-User Space FIFO) is assuming a certain amount of data will be
present or if you are counting on timing / spacing for different data types,
etc. All of these are, of course, bad practices.
If you are certain that you have enough processor time to handle all
of the non-RT data, just not at the particular time that it is being
written, you can always make the FIFOs larger. I am amazed at how many
problems I have seen where others have used FIFOs with 64 bytes of space on
a 64MB machine. I always use at *least* 16384 for my FIFO sizes and often
go up from there if there is *any* question as to how full the FIFO will
get.
You might want to periodically check on the usage of your FIFO and
report it to a logging task via *another* FIFO for debugging / sizing
purposes. To find the free space in the FIFO, just use something like:
free_FIFO_space = (&rtl_fifos[fifo_number]->bufsize -
&rtl_fifos[fifo_number]->len)
A check and report after every rtf_put should give you a good idea
as to how much FIFO you are really using (on that machine). You can then
apply a sensible engineering overhead based on what you expect to see on
your real target machine, etc. I would make sure that the FIFOs are never
more than 50% full on my target machine unless I was *severely* starved for
memory.
Regards,
Steve Cohen
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/