On 2009-03-12, Jamie Lokier <ja...@shareable.org> wrote:
> Grant Edwards wrote:
>> > or do the hard realtime stuff in hardware (if same can be
>> > reduced to very simple functions).
>>
>> 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'm surprised nobody has mentioned the real-time Linux patches
> :-) Specifically the PREEMPT_RT tree.
Is there support in ucLinux on the NIOS?
> The advantage of their method is that RT processes have access
> to all the normal Linux features - in kernel space and
> userspace.
>
> You lose the RT aspect temporarily while you do something that
> you couldn't expect to be RT anyway, like read a file, or a
> pipe waiting for a non-RT process, but at least you can do
> those things when its useful, and get RT properties when
> you're not doing such things.
That sounds like it ought to solve the problem.
> With network prioritisation and the experimental
> process-context TCP stack (which is not in the kernel), you
> might realistically be able to reply to a message over TCP
> with RT timing.
My requirements shouldn't even require network prioritisation.
I wouldn't expect the in-kernel network stack is where the 10ms
of latency is coming from (thought I haven't figured out how to
prove it isn't). Latency in scheduling of user-space threads
has always been the main suspect.
--
Grant Edwards grante Yow! I'm ANN LANDERS!!
at I can SHOPLIFT!!
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
