Tomasz,
Thanks for the reply.
> 1. recompile your kernel with HZ defined to 1000 or 2000
> in include/asm/param.h. Then you can get granularity of 1-2 ms with normal
> Linux kernel. You can use soft real time to make it smoother
> (sched_setscheduler, sched_setparam).
As a matter of interest what exactly does this parameter do? I don't
really do much with the kernel sources. I assume it somehow hardware
dependent as to the value you can realistically set this? I can't imagin
its how long the kernel take until is context switches. The current
setting is 100, it would be dog slow! :)
> 4. Hard real time is not an option for you because your application is user
> and communication oriented. Missing deadline by 1 ms few times per day is not
> a problem for you. Hard real time is really for tasks which read something
> from IO (and possibly calculate and write something back), with catastrophic
> results of beeing 100 microseconds late.
Yes. I realise that this is not a partularly RT situation. It was just
something that I was going to try out first. But ensuring the
pacing between frames IS an important issue (This is a test/traffic
generator. Therefore it's not strictly communication). If you miss the
deadline by a few ms then, depending upon how many frames/per second the
user has requested 100,2000, 10000... you'll have to blast out a bunch of
them. This make the LAN traffic very spikey, and prone to collisions. So I
thought using a RT period task to do the job would increase the
resolution.
However I've read some other documents as realise that without
semi-rewritting the NIC driver so it works in the RT domain the project
would be rarther pointless. However I did set a port of the tulip.c
driver. Could use that.
However, I also would like to use RTL in my robotic applications. This
require a much sharper responce. Velocity measurement, Image Capture
(Custom built hardware - Capturing Horz and Vertical Sync pulses in
partucular) etc
Regards
Mark
>
> On Fri, 26 May 2000, Mark wrote:
>
> > 1) I've read some of the documentation and it seems that most of the RT
> > suff is a thread. The thing that confuses me here is that I thought a
> > thread executed separately within a process. Therefore what process is
> > this? Does it mean that the "normal" Linux process has a real time
>
> The kernel, including all user processes is the lowest priority RT thread
> within RT scheduler.
>
> Best regards,
> --
> Tomek
>
-- [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/
