On 2009-03-13, Michael Schnell <mschn...@lumino.de> wrote:
>> 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.]
>
> Did you test the NICHE-Stack (e.g. for NIOS). Same seems to
> work without any OS. So you might in fact use a second NIOS
> just for Ethernet communication and run the NICHE stack on
> same. (Your extremely demanding realtime-IP requirements _do_
> ask for a very creative solution.
Not really. My current solution using eCos (with he FreeBSD
TCP/IP stack) works fine: there's only a few hundred
microseconds of latency.
We were hoping to be able to use uClinux on some products in
order to ease the effort required in porting various
non-realtime application code that was originally developed
under Linux.
> So I suppose you will not get away with a "standard" thingy
> but need something more complex that - of course - needs some
> more debugging efforts.)
>>> Why in fact do you want to use userland threads?
>>
>> Are you suggesting I put my entire application in a kernel
>> module?
>
> No. And in fact I doubt that this will help. A
> "realtime-priority" userland process should offer very similar
> latency as a kernel module,
It certainly doesn't work that way on NIOS/ucLinux. Kernel
latency appears to be in the 0.1ms range.
> as with newer 2.6 Kernels versions, the "piority inversion"
> problem (a low priority process is not interrupted by a hight
> priority thread (if same gets active due to some event) while
> the low priority process is doing a system call) seems to be
> largely taken care of (if you set the appropriate options when
> compiling the Kernel). I suggest, in your userland program,
> not using threads but a "run to completion" paradigm.
You keep saying that, but I can't figure out what you're
talking about. My threads _do_ run to completion.
> With that task switches are reduced (reducing the CPU load)
> and the application performance gets more deterministic. But
> this might increase the latency of certain parts of the
> application, which might be better when done in a dedicated
> thread.
I'll try to be clear: I've got a threaded application. It
works fine with eCos. I want to run the same code on Linux
without adding a lot of latency. I'm not interested in advice
on how to completely redesign the application for use without
an OS. The goal is to run in on ucLinux. I thought this would
be an appropriate forum for discussing that.
>> The application in question is using a run-to-completion
>> paradigm (that's what you get with SCHED_FIFO in pthreads).
>
> Maybe, but if you really want this (the threads can't
> interrupt each other), you can do this explicitly in your
> application without pthreadlib or something similar. Another
> advantage is that you don't need any complicated inter-thread
> communication and protection of multiple access for variables.
I don't really have any complicated inter-thread communication.
> This might avoid a lot of trouble and save a lot of
> CPU-cycles.
>
> I created a simple architecture-independent set of macros, I
> call "PICO-OS", for this purpose. I use it as well instead of
> a real OS for very small microcomputers as for
> process-internal cooperative multithreading within an
> application.
We're not talking about a very small microcomputer. We're
talking about a 100MHz 32-bit CPU with tens of megabytes of
memory running applications in the 1-2MB range.
>> 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.
>
> "Run to completion" usually is done by having an interrupt set
> a flag and schedule the multiple functions ("tasks") of the
> application according to the flag (and reset it). So only what
> needs simple direct response (such as resetting the interrupt
> cause) is done in the interrupt and the rest is done in a
> "task". This in effect of course creates a quite large but
> well defined maximum latency.
You've lost me. AFAICT, that's pretty much how both Linux and
all the RTOSes I've ever seen work.
>> For what I'm doing, just reducing the scheduling latency on an
>> idle system to <1ms would be fine.
>
> ... but supposedly not doable with "standard" means ("Linux is
> not realtime").
If Linux can't do it, then Linux can't do it. I've already got
a threaded, non-Linux solution that works fine. What I was
looking for was a Linux solution.
--
Grant Edwards grante Yow! I'm into SOFTWARE!
at
visi.com
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
