Joel Winarske wrote:
> Hi folks,
Hi, Joel
> I have a RS485 device that requires 700us (typ), 2ms (max) response
> time. I am
> considering the TS-7400. So device needs to respond to master within 2ms.
>
> What sort of latency could I expect to see from Linux?
It depends on what flavor of Linux we're talking about. You can go from
a no CONFIG_PREEMPT kernel up to linux-rt with full PREEMPTION
(including IRQ handlers).
linux-rt is a huge effort from Ingo Molnar and others to build some
real-time infrastructure into the standard kernel. I remember from
memory some benchmarks on a PC that held something like less than 10us
average latency, max 50us.
This was with the machine running some stress-test userspace apps
(network, disk, memory) and the measurement is the time it takes for an
external event (toggling a pin, or something) to awake a process and
make it runnable. So, even though the ARM should be somewhat slower, the
700us requirement should be perfectly attainable.
> Is the latency deterministic?
The bad news is that under linux-rt the latency is only statistically
deterministic, i.e., extensive tests have been made to show that there
are no huge latency paths in the kernel, but there is no absolute
guarantee that a rogue driver can not old the CPU for more than your
expected latency.
The good news is that you don't need anything special to use the
real-time functionality. You just give your process some high real-time
priority and it will preempt anything under the assigned priority. It
even has priority inheritance, so that if your process is waiting for
some resource held by a lower priority task, that task is temporarily
given the same priority as your process until it releases the resource
you need.
You can check it here:
http://people.redhat.com/mingo/realtime-preempt/
You will need a 2.6 kernel, though. The problem is that not all TS-7400
devices are supported on a 2.6 kernel ATM :(
> How would Ethernet or USB activity affect this?
Under full linux-rt, even IRQ's are treated as processes with their own
priorities. If your process is more important to you than receiving an
ethernet frame, you can simply set a higher priority to it than to your
ethernet IRQ handler.
Note that you can completely hang your machine by setting a very high
real time priority to a process and then making it enter an infinite loop.
> Can I shift kernel task priorities around?
Yep. You just have to make sure that your devices can handle "high" IRQ
delivery latency. Since the IRQ handling code will only run in its own
priority, the hardware device must wait until the IRQ handler is awaken.
Anyway, if you're going through this route, you still have a long way to go.
If I were in your shoes (I hope you wear the same size) I would start by
testing with a vanilla 2.6 kernel with CONFIG_PREEMPT. This will
probably already give you a good latency and you might avoid the hassle
of patching and running a bleeding edge linux-rt kernel.
Good luck,
--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com
"The face of a child can say it all, especially the
mouth part of the face."
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|