Kate Alhola wrote: >> Kate Alhola wrote: >>> Is it possible to use RTnet without specially ported network drivers >>> and routing trafick via standard Linux network driver ? >> Nope, that is not possible ATM. [I may become feasible in the far future >> when PREEMPT_RT matured and netchannels or something similar >> materialised and we make use of it.] >> >>> In my mind something like using RTmac and rt_loobback drivers >>> or is there siome other way ? >> No, this has nothing to do with it. The rt_loopback driver provides a >> RTnet-internal loop. And RTmac is the framework to add software-based >> media access control to RTnet's NIC drivers. > > I had in my mind http://www.rts.uni-hannover.de/rtnet/images/network.gif > image. The leftmost Linux box has both normal linux ethernet card > and rtnet interface. If we just replace the rtnet interface with loopback, > should the routing functionality still exist ?
What is emphasised in this picture is the clear separation of RT and
non-RT networks and the non-RT tunnelling from the "outside". Routing
between both network domains is feasible but requires your application
to take care of it. Some kind of borderline thread could read RT
messages and put them in the non-RT domain (and vice versa). It will
then be switched back and forth between RT and non-RT mode when doing
this (given that you are in user-space...).
>
> I don't even consider any user mode solution, then there comes
> ann contxt switch and scheduling latensies and with them 1ms
> is about inpossible.
Have you measured those latencies on your target? The price on low-end
is about a few 10 us. Simple 10-KHz loops on a 133 MHz Pentium, e.g.,
are schedulable reliably - in user-space.
>
>>> I understand that TDMA and hardest real time is lost but
>>> at the moment, my target is just get 1ms cyckle time
>>> from RTAI. My goal is just use microcontroller as
>>> I/O module for RTAI.
>> Hard RT has nothing to do with 1 ms vs. 0.1 ms or whatever. It's about
>> if you can tolerate deadline misses or not. Even a 1 ms loop can already
>> be stressing for a loaded low-end processors.
>
> I understand this and understand also that with loaded ethernet
> there is no possibility to hard real time. My idea was just have
> dedicated lightly loaded machine and no-load or just administrative
> wery light load ethernet interface. 100Mbit ethernet interface can
> still send 6 full sized 1500 byte packets or hundred small ssh etc
> packets per second so with no-load or light load there liest
> will bee free slots to send my packets with 1ms loop.
Then go for Linux, use traffic shaping or prioritise your traffic, and
handle the case that once in a while your packet could miss a deadline
(even on lightly loaded boxes).
BTW, to reduce the risk, the Xenomai framework offers priority
inheritance to the Linux service a RT task invokes. Additionally, it can
switch off further IRQ delivery to Linux ("IRQ shield") while executing
that service (e.g. sendto...). Still not hard-RT, but better than
CONFIG_PREEMPT alone.
>
>> So, do you have hard requirements to meet your 1-ms deadline?
>
> I need to have this 1ms, the net can be dedicated and machine light
> loaded but i can't be fixed in some specific network card.
You have to pick one, you can't have both hard-RT + hardware
independence ATM.
>
> As other solution i had in my mind just to use ip_finish_output(skb)
> to send udp packets from RTAI and dev_add_pack() to add my own packet
> handler. Or may be just use them to implement pseudodriver for
> RTnet that just sends and receives packets via Linux stack.
Check the virtual NIC in RTmac or the rtnetproxy for design patterns.
Again: both have to switch to Linux in order to issue the transmission.
Never try this from RT context, because that context is completely
asynchronous wrt Linux (causes nice crashes once in a while when being
ignored).
>
>
>> Jan
>>
>>
>> PS: Just read your RTAI posting: Don't assume user-mode==non-RT.
>> Execution context (RT/non-RT) and mode (kernel/user) are orthogonal. In
>> fact, hardly anyone should start new RT application designs in kernel
>> space today.
>
> I am somihow familiar with this, i have also user Ingo Molnar
> Pre-Empt/low latency patches. At this time i just need to make
> Ethernet interface to microcontroller from EMC
Ah, EMC, that's the reason for your kernel preference. Yep, existing
apps can still force one to stay there for now. I hope they will enhance
their framework one day. Applications like this also make people believe
that RT==kernel-space.
Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
