On 2009-03-12, Michael Schnell <[email protected]> wrote:
>
>> Um, isn't that what RTAI does -- run the linux kernel on a
>> virtualized processor?
>
> Yep, but AFAIK, in the "realtime" part, you need to use what RTAI
> offers. You can't install some RTOS there.
True. RTAI is sort of a combination of a virtualized processor
and an RTOS. That limits your flexibility, but saves you from
having to port an RTOS.
>> As one of my friends used to say: "the only thing worse than a
>> product based on a microprocessor is one based on two of
>> them."
>
> So don't use a car ! They include hundreds of them :)
Hundreds? I would have believed 25-50...
The difference is that automakers can afford mind-bogglingly
huge NRE costs. [Well, they used to be able to.] Additionally,
the costs of the processors in a car are completely
insignificant compared to the price of the product.
>> That last qualification is an important one. When I've asked
>> in the NIOS forums about RTAI or other ways to control latency
>> on the NIOS/Linux platform, the answer is always "do it in
>> hardware!". That's fine if you have to toggle pin B whenever
>> pin A changes, but for things like replying to a message on a
>> TCP connection such advice is utterly useless.
>
> I feel that replying to a message on a TCP connection is not
> doable as a really hard realtime task.
That depends on what the specs are.
> There are things like "realtime Ethernet", but I doubt that it
> can be used with RTAI and that it can live together with
> Linux. You would need to do the complete IP-stack within the
> realtime part of the application. Do you in fact have access
> to code for such a "realtime Stack" starting from the Ethernet
> driver and featuring a complete "zero-copy" UP-stack?
Real time doesn't imply zero-copy. _Fast_ implies zero-copy.
For example, I can live with a response time of 3-3.5ms I can't
live with a resonse time of 3-13ms. In both cases, the 3ms
minimum response time is fine. It's the random 0-10ms of
additional latency you get with uClinux on NIOS that's the
problem. [Those are actual numbers I got when comparing the
same application run on eCos and on uClinux on the NIOSII.]
> I suppose this code would be done for a dedicated processor
> and OS (supposedly not RTAI). I do have access to such code
> (propriety by Ubicom). same is especially made for GBit Router
> applications.
>
>> Not only does NIOS lack RTAI/Xenomi support, it doesn't even
>> have NPTL support. That means that scheduling of threads is
>> being done by user-space code. Yes, that results in really
>> bad scheduling latencies (on the order of 5-10ms in my
>> experience).
>
> You are right here (I'm disappointed about this myself). But
> AFAIK, no code for the IP-Stack is done with userland threads.
Unfortunately, the IP stack doesn't really know how to do much. :)
> Why in fact do you want to use userland threads?
Are you suggesting I put my entire application in a kernel
module? If you do that you loose all of the advantages of
using Linux, and you might as well stick with an RTOS. Even
application using an RTOS tend to be more portable and
maintainable than Linux kernel modules.
> In most applications (unfortunately not in mine) it's better
> to use a "run to completion" paradigm instead of doing a
> multithreaded userland application.
The application in question is using a run-to-completion
paradigm (that's what you get with SCHED_FIFO in pthreads).
Or by run-to-completion, do you mean that the ISR does
absolutely everything, and nothing is deferred to a tasklet or
thread? For anything non-trivial, I find that approach quickly
becomes unmanagable.
> Here again, the hardware-multithreaded Ubicom CPU (and SDK)
> provides a perfect solution for applications that ask for
> multithreaded development. As said, they seem to be planning
> an implementation of SMP-Linux on top of this. Here you'll
> have a realtime IP stack, Linux, and perfect thread
> scheduling, but you'd need to use (and buy) their propriety
> SDK :(.
For what I'm doing, just reducing the scheduling latency on an
idle system to <1ms would be fine.
--
Grant Edwards grante Yow! FEELINGS are cascading
at over me!!!
visi.com
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
