I'm still trying to circle and isolate this bug. The user side process
definitely can simply stop being "select" triggered on an rtfifo after
extended running of 50-150 minutes.
The user process logic simply is:
starts loop
does a select on the input rtfifo
when select is triggered it reads 1k from the fifo
it then writes bytes back to output rtfifo
write a console message every n counts (~every 5 sec)
loops
Has anyone experienced similar problems with select and rtfifo's?
Does anyone know what might cause the select command to "skip" or miss
events? My current best theory is that however this happens it happens for
a long enough swatch of time that the rtfifo fills. If rtf_put fails to
put bytes to a full fifo ... I'm assuming that select will never retrigger.
I'm going to modify my code to "catch" the error condition of a full fifo
to see if that coincides with the "stall" event. Does this sound like a
good theory?
Does anyone know if the write to a full rtfifo will hang or simply return
with an error?
I've already tried
- expanding the rtfifo sizes to 16k
- expanding my prepack buffer in the RT side to 512bytes (which lowers the
frequency at which the select command is dinged to 16Hz)
Neither of these had any significant effect on making this code run longer.
It always stalls in that 50-150minute window with a lot of disc thrashing
noises.
Any advice would be appreciated. Thanks.
>Date: Thu, 22 Jul 1999 07:38:27 -0400
>To: <[EMAIL PROTECTED]>
>From: Robert Findlay <[EMAIL PROTECTED]>
>Subject: [rtl] re: rtfifo full problem
>
>I have developed an application under RTL1.1
>
>It consists of an RT module which gathers data at 8kHz from some hardware
>and pumps it out an rtfifo in 100 byte chunks. The user process does a
>select on that fifo followed by a read. In the mode I'm running at
>present the user process is set into "loopback" so it takes that chunk
>being read and writes it immediately to another rtfifo. My RT module has
>a handler installed which writes the incoming bytes back to the hardware.
>
>This is all being run on a 200MHz+ Pentium class machine.
>
>It runs flawlessly for several hours. At some point the harddisc starts
>to thrash and my user process stops being dinged on the select. All the
>processes are still running (because I have my RT module writing a
>heartbeat message to another rtfifo every 5 seconds or so).
>
>Is there some background process in Linux which comes along periodically to
>do lots of disc I/O which would disrupt my user process sufficiently to
>cause my 4k rtfifo to overflow? If so how can I overcome this in my
>design? Is there a way to "detect" depth in my rtfifo? (I know there is
>something on the RTLinux site which writes to /proc)
>
>Thanks.
>--- [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/
>
>
Robert D. Findlay
Senior Software Engineer
FC software Inc.
Tel: (905)659-0512
email: [EMAIL PROTECTED] Web: www.netcom.ca/~fcsoft
--- [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/
