> What you have not told us is how long does it take to complete the 50 mS
> task and the 500 mS task (worst case and average case)?
>
I think the demand of the 50ms-tasks will be between 5 and 30ms, and
of the 500ms-ones it will be 40 to 80ms, depending on the data and
CPU capacity.
> The reason I ask is that 50 mS is on the boundary of Linux's
> responsiveness. In a RTL paper I read it said that the responsiveness
> of Linux was in the 30 mSec to 50 mSec range, and that setting RTL tasks
> to execute at less than 50 mSec caused Linux tasks to be noticeably
> affected. Setting RTL tasks in the uSec range like at around 100 uSec (
> if I remember (correctly ) caused Linux to freeze 100 percent.
>
Hm, I might be able to increase this smaller period up to 100ms. (BTW,
has anyone had that problem with periods longer than ~850ms? I added
some a (long long) cast but it still does not work under the
rate-monotonic scheduler.)
> I agree fully with the 'priority inversion' problem caused by placing
> the networking at a low priority level in Linux while running RTL.
> Networking should all be in RTL. As should all hardware device drivers.
>
> Until then you can do the following to help time-critical apps:
>
> - set the privilege for your linux TCP/IP process (your app) to
> superuser
> - read the scheduler function calls in sched.h
> - set linux for round robin scheduling
> - set your TCP/IP process to priority 99 in round robin.
> - set the round robin time slice to a value at least greater than your
> TCP/IP process message send time.
>
Thanks, I will have this in mind when trying to get the most of it.
> You can also do the following:
>
> Reduce the workload on normal Linux. Shutdown any daemons, and other
> background tasks that are not absolutely essential. If you are sending
> JPEG then I suspect that you may be running X and some X apps. If you
> can do with out X or some of the X apps try it. Also, even if you can't,
> try it anyway just to verify that this is the problem. Test this
> hypothesis by running just the RTL and console mode Linux with no apps,
> daemons, or other background tasks running on both the sender and
> receiver. If you have successfully ruled out network congestion and
> buffering, then I suspect the reason that it sometimes takes 16 secs to
> send your data is because some Linux tasks (maybe kernel level daemons)
> are intermittently becoming active and competing for resources. If this
> is not the cause then at least by following the above procedure you can
> rule it out.
>
I am not using JPEG nor X, but a raw image format for a specific
application. I think those 16 seconds might have to do with flushing
stdout for debugging purposes on a Solaris client. When I turned off
all debug info printing at the client end, the problem seemed to
disappear. (I underestimated this effect...)
> Also, the system command 'ptree' will list all of the processes
> currently running.
>
> - Kal.
>
Thanks for your help! I had to work on fixing some other bugs in the
application, but now I should be able to do more testing of these things.
Aleks
--- [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/
