rtnet-developers — development-related list

[RTnet-developers] Multicast support for RTnet

[amine <am...@an...>]

Hi ,



-- 
EL HEDADI Amine
R&D
phone : 
Email : am...@an...

[RTnet-developers] RTDM merge in SVN

[Jan K. <jan...@we...>]

Hi,

short update on the current SVN status:

* new RTDM branch has been merged, RTnet currently only compiles against
  fusion-CVS

* old RTDM module has been cleanup with respect to fusion code, however,
  it is not yet updated with respect to RTAI/classic (same applies to
  stack/include/rtnet_sys_rtai.h)

* all TDMA-V1 stuff has been cleaned up

* TDMA (i.e. V2) is now an optional component (default: on)

I'm now considering to separate the UDP/IP and Packet protocols from the
core and turn them into modules as well. Should be possible now as no
other module depends on them anymore (TDMA-V1 used to).

Happy WE,
Jan

[RTnet-developers] RTNET on RTAI r3.04/pentium2 pci/tulip - (single host) system hang

[Howard C. <hc...@uv...>]

Hi, List member:

I really need to set up the RTNET work so that I can use the the socket/UDP
interface in RTAI kernel real time task. (I do not care is hard real time
or soft real time at this moment, the first step is make my hard real
time task can do network IO with the outside - no real time host at this
time, since I only have one PC - I am doing some Qos experiment on the
processor level, not at the IO level at this moment)


My Goal is very simple at this stage:

** I can send/receive packets use UDP socket in RTAI kernel RTtask.
** No real time for now and on a single linux/rtai/rtnet machine.
** I guess in this case, regular linux network is fine as well, right?

!!!! Helps are greatly appreciated !!!!

I tried before, local RT interface is up running, but can not be in the 
network.
RTPing outside did not work.

Tonight I tried from the begin again.

Here is the detailed cmd procedure (I did)
Since I only have one RTAI/Rtnet station, I do "rtnet capture", while 
the whole system seem become frozen.
My PC (dhcp client) is running inside a linux router which connect to cable 
modem.

Details Commands:
==================

1. booted with RTAI kernel. network and network application
is ok. (ping www.yahoo.com ok, dhcp got IP address and ok)

 
2 Check loaded module.
[root@howard-pc realtime]# lsmod
Module                  Size  Used by    Not tainted
tulip                  45632   1  (autoclean)
crc32                   3592   0  (autoclean) [tulip]
[root@howard-pc realtime]#

 
3. ifconfig eth0 down
4. rmmod tulip
[root@howard-pc realtime]# ifconfig eth0 down
[root@howard-pc realtime]# lsmod
Module                  Size  Used by    Not tainted
tulip                  45632   0  (autoclean)
crc32                   3592   0  (autoclean) [tulip]
[root@howard-pc realtime]# modprobe -r tulip
[root@howard-pc realtime]# lsmod
Module                  Size  Used by    Not tainted
#
#modprobe -l
#modprobe -l
/lib/modules/2.4.25-rthal5/kernel/drivers/net/dummy.o
/lib/modules/2.4.25-rthal5/kernel/drivers/net/eepro100.o
/lib/modules/2.4.25-rthal5/kernel/drivers/net/mii.o
/lib/modules/2.4.25-rthal5/kernel/drivers/net/ppp_async.o
/lib/modules/2.4.25-rthal5/kernel/drivers/net/ppp_generic.o
/lib/modules/2.4.25-rthal5/kernel/drivers/net/ppp_synctty.o
/lib/modules/2.4.25-rthal5/kernel/drivers/net/slhc.o
/lib/modules/2.4.25-rthal5/kernel/drivers/net/slip.o
/lib/modules/2.4.25-rthal5/kernel/drivers/net/tulip/tulip.o
/lib/modules/2.4.25-rthal5/kernel/drivers/sound/ac97_codec.o
/lib/modules/2.4.25-rthal5/kernel/drivers/sound/emu10k1/emu10k1.o
/lib/modules/2.4.25-rthal5/kernel/drivers/sound/es1371.o
/lib/modules/2.4.25-rthal5/kernel/drivers/sound/sonicvibes.o
/lib/modules/2.4.25-rthal5/kernel/drivers/usb/audio.o
/lib/modules/2.4.25-rthal5/kernel/lib/crc32.o
#root@howard-pc realtime]# lsmod
Module                  Size  Used by    Not tainted
#



 
[root@howard-pc realtime]# ps -ef |grep dhcp
root     11532     1  0 22:16 ?        00:00:00 /sbin/dhcpcd -n eth0
root     11573 11333  0 22:33 pts/2    00:00:00 grep dhcp
[root@howard-pc realtime]# kill 11532
[root@howard-pc realtime]# ps -ef |grep dhcp
root     11614     1  0 22:34 ?        00:00:00 /sbin/dhcpcd -n eth0
root     11644 11333  0 22:34 pts/2    00:00:00 grep dhcp
[root@howard-pc realtime]# kill 11614
[root@howard-pc realtime]# ps -ef |grep dhcp
[root@howard-pc realtime]# ps -ef |grep dhcp
root     11648 11333  0 22:34 pts/2    00:00:00 grep dhcp
#
[root@howard-pc modules]# ps -ef |grep dhcp
root     11672 11333  0 22:39 pts/2    00:00:00 grep dhcp
[root@howard-pc modules]# lsmod
Module                  Size  Used by    Not tainted
[root@howard-pc modules]#

 
### Network device is down ############
# load RTAI #
[root@howard-pc realtime]# cd modules
[root@howard-pc modules]# pwd
/usr/realtime/modules
[root@howard-pc modules]# ls -al
total 416
drwxr-xr-x    2 root     root         4096 Nov  2  2004 .
drwxr-xr-x    9 root     root         4096 Jul 30  2004 ..
-rw-r--r--    1 root     root         7358 Jul 30  2004 rtai_bits.o
-rw-r--r--    1 root     root        22637 Jul 30  2004 rtai_fifos.o
-rw-r--r--    1 root     root        27068 Jul 30  2004 rtai_hal.o
lrwxrwxrwx    1 root     root            9 Nov  2  2004 rtai_ksched.o -> 
rtai_up.o
-rw-r--r--    1 root     root         3078 Jul 30  2004 rtai_leds.o
-rw-r--r--    1 root     root        68494 Nov  2  2004 rtai_lxrt.o
-rw-r--r--    1 root     root        34910 Jul 30  2004 rtai_math.o
-rw-r--r--    1 root     root         8834 Jul 30  2004 rtai_mbx.o
-rw-r--r--    1 root     root        25184 Jul 30  2004 rtai_mq.o
-rw-r--r--    1 root     root        16679 Jul 30  2004 rtai_msg.o
-rw-r--r--    1 root     root        20625 Jul 30  2004 rtai_netrpc.o
-rw-r--r--    1 root     root        13927 Jul 30  2004 rtai_sem.o
-rw-r--r--    1 root     root        15536 Jul 30  2004 rtai_serial.o
-rw-r--r--    1 root     root        10357 Jul 30  2004 rtai_shm.o
-rw-r--r--    1 root     root         8275 Jul 30  2004 rtai_tasklets.o
-rw-r--r--    1 root     root        15278 Jul 30  2004 rtai_tbx.o
-rw-r--r--    1 root     root        49629 Nov  2  2004 rtai_up.o
-rw-r--r--    1 root     root         5167 Jul 30  2004 rtai_usi.o
-rw-r--r--    1 root     root        15004 Jul 30  2004 rtai_wd.o
[root@howard-pc modules]#
[root@howard-pc modules]# insmod ./rtai_hal.o
[root@howard-pc modules]# lsmod
Module                  Size  Used by    Not tainted
rtai_hal               39552   0  (unused)
[root@howard-pc modules]# insmod ./rtai_ksched.o
[root@howard-pc modules]# insmod ./rtai_sem.o
[root@howard-pc modules]# lsmod
Module                  Size  Used by    Not tainted
rtai_sem               12160   0  (unused)
rtai_ksched            46197   0  [rtai_sem]
rtai_hal               39552   1  [rtai_sem rtai_ksched]
[root@howard-pc modules]#

 
# check /dev/rtnet
#ls -la /dev/rtnet
crw-r--r--    1 root     root      10, 240 Sep 30  2004 /dev/rtnet

 
#
[root@howard-pc rtnet]# cd modules
[root@howard-pc modules]# pwd
/opt/rtnet/modules
[root@howard-pc modules]#

 
[root@howard-pc modules]# insmod ./rtai_rtdm.o
[root@howard-pc modules]# lsmod
Module                  Size  Used by    Not tainted
rtai_rtdm              13044   0  (unused)
rtai_sem               12160   0  (unused)
rtai_ksched            46197   0  [rtai_rtdm rtai_sem]
rtai_hal               39552   1  [rtai_rtdm rtai_sem rtai_ksched]

 
## RTNET Configureation options ##

 
[root@howard-pc rtnet-0.7.1]# ./configure --with-rtai=/usr/realtime 
--prefix=/opt/rtnet --enable-allpci --enable-proxy --enable-rtcap 
--enable-net-routing --enable-router
###

###### /etc/rtnet.conf #####
#!/bin/sh
#
# Copy this file to /etc/rtnet.conf and adapt it to your system.
# This configuration file is used with the rtnet script.
#

 
# RTnet installation path
RTNET_PATH="/opt/rtnet"

 
# RT-NIC driver
#RT_DRIVER="eepro100-rt"
RT_DRIVER="tulip-rt"
RT_DRIVER_OPTIONS="cards=1"

 
# IP address and netmask of this station
IPADDR="192.168.1.101"
NETMASK="255.255.0.0"

 
# Start realtime loopback device ("yes" or "no")
RT_LOOPBACK="yes"

 
# Start capturing interface ("yes" or "no")
RTCAP="no"

 
# Common RTcfg stage 2 config data (master mode only)
STAGE_2_SRC=""

 
# Stage 2 config data destination file (client mode only)
STAGE_2_DST=""
# Command to be executed after stage 2 phase (client mode only)
STAGE_2_CMDS=""

 
# TDMA mode of the station ("master" or "client")
TDMA_MODE="master"
#TDMA_MODE="client"

 
# List of TDMA clients (master mode only)
#TDMA_CLIENTS="10.0.0.2 10.0.0.3 10.0.0.4"
TDMA_CLIENTS=""

 
# Cycle time in microsecond (master mode only)
TDMA_CYCLE="5000"

 
# Offset in microsecond between TDMA slots (master mode only)
TDMA_OFFSET="200"


Regards,

Howard.

[RTnet-developers] rtnet & fusion

[<am...@an...>]

Hi
I want to test rtnet-0.8.2 with fusion ,can you tell me where can I download 
the fusion 0.7.1 : 0.7.4 , because i have only find the fusion 0.7 & fusion 
0.8 in the RTAI web site.

think for your help.

Re: [RTnet-developers] multicast support

[Jan K. <ki...@rt...>]

Amine El hedadi wrote:
> Hi jan;
> 
> 
>>What about  rt_ip_route_output()? Doesn't it exactly do what you need? It
>>fills a dest_route structure which then contains a pointer to the output
>>rtdev. Take a look at rt_udp_sendmsg() for a usage example.
> 
> That's ok,   rt_ip_route_output() give a pointer to the output rtdev , but 
> only in the case when we add the multicast adress to route table :
> # rtroute add 239.0.0.2 01:00:5e:00:00:01 dev rteth0 , that work well,
> But in the case of multicat, we can calculate the mac address  from the IP 
> address  without using routing table.
> So i have added a conditions test before the call of the 
> "rt_ip_route_output()" in udp_sendmsg function
> if the dist address is multicast  i calculate the mac adresse and i locate the 
> rtdev by the local address (saddr).
> 

Well, I would prefer some solution that actually creates such a routing 
table entry. Not yet sure how this may look like. Either we have to 
distribute this setup via RTcfg to the stations or some socket ioctl or 
sockopt has to be introduced to create the routing table entry on 
demand. The advantage: this avoids the additional check in the 
transmission path for both multicast and unicast packets.

> So nowday Im able to recive and send mulicast packets with rtnet .Im testing 
> it now and i will send you  a first realise of my patch soon.
> PS : i have only enabled the multicast support for the two NICs ,8139too et 
> e100.
> 

Great, looking forward!

Jan

Re: [RTnet-developers] multicast support

[Amine El h. <am...@an...>]

Hi jan;

> What about  rt_ip_route_output()? Doesn't it exactly do what you need? It
> fills a dest_route structure which then contains a pointer to the output
> rtdev. Take a look at rt_udp_sendmsg() for a usage example.
That's ok,   rt_ip_route_output() give a pointer to the output rtdev , but 
only in the case when we add the multicast adress to route table :
# rtroute add 239.0.0.2 01:00:5e:00:00:01 dev rteth0 , that work well,
But in the case of multicat, we can calculate the mac address  from the IP 
address  without using routing table.
So i have added a conditions test before the call of the 
"rt_ip_route_output()" in udp_sendmsg function
if the dist address is multicast  i calculate the mac adresse and i locate the 
rtdev by the local address (saddr).

So nowday Im able to recive and send mulicast packets with rtnet .Im testing 
it now and i will send you  a first realise of my patch soon.
PS : i have only enabled the multicast support for the two NICs ,8139too et 
e100.


Amine

> Hi Amine,
>
> sorry for the late reply.
>
> >>What are you actually planning? Likely there is a different way to
> >>achieve it
> >
> > TO send an IGMP request to join a multicast goup ,the only information i
> > had is the rt_socket ,and i need to send directly the igmp packet without
> > passing by the ip level , that mean to use directly the xmit_start
> > function ,to use it i need rtnet_device pointer. you see the problem i
> > had ?
> > So I have resolved the problem by adding a new function in "rtdev.c", its
> > role is to get rtnet_device by local_ip  adress.it work well. The only
> > constrain that we must specify the local ip adress when using multicast.
>



>
> Jan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you
> shotput a projector? How fast can you ride your desk chair down the office
> luge track? If you want to score the big prize, get to know the little guy.
> Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
> _______________________________________________
> RTnet-developers mailing list
> RTn...@li...
> https://lists.sourceforge.net/lists/listinfo/rtnet-developers

Re: [RTnet-developers] multicast support

[Jan K. <ki...@rt...>]

Hi Amine,

sorry for the late reply.

>>What are you actually planning? Likely there is a different way to 
>>achieve it
> 
> TO send an IGMP request to join a multicast goup ,the only information i had 
> is the rt_socket ,and i need to send directly the igmp packet without passing 
> by the ip level , that mean to use directly the xmit_start function ,to use 
> it i need rtnet_device pointer. you see the problem i had ?
> So I have resolved the problem by adding a new function in "rtdev.c", its  
> role is to get rtnet_device by local_ip  adress.it work well. The only 
> constrain that we must specify the local ip adress when using multicast.
> 

What about rt_ip_route_output()? Doesn't it exactly do what you need? It 
fills a dest_route structure which then contains a pointer to the output 
rtdev. Take a look at rt_udp_sendmsg() for a usage example.

Jan

Re: [RTnet-developers] multicast support

[Amine El h. <am...@an...>]

hi
>What are you actually planning? Likely there is a different way to 
>achieve it
TO send an IGMP request to join a multicast goup ,the only information i had 
is the rt_socket ,and i need to send directly the igmp packet without passing 
by the ip level , that mean to use directly the xmit_start function ,to use 
it i need rtnet_device pointer. you see the problem i had ?
So I have resolved the problem by adding a new function in "rtdev.c", its  
role is to get rtnet_device by local_ip  adress.it work well. The only 
constrain that we must specify the local ip adress when using multicast.

Re: [RTnet-developers] multicast support

[Jan K. <ki...@rt...>]

Amine El hedadi wrote:
> Hi 
> 
> It is possible to get rtnet_device pointer form rtsocket pointer.
> for example    struct rtnet_device *rtdev= xxxxx(struct rtsocket sk);
> I can't find any way to do that 

There is no static relation between a socket and some network device. A 
socket can be used to transmit or receive packets from different 
devices. You can change this situation for UDP/IP by binding a socket to 
a local IP (i.e. device) or by connecting with some remote IP (i.e. 
preselecting the output device). But as IPs and routes may change, there 
is no fixed pointer stored in the socket structure even in this cases. 
Intead, packets are analysed on reception if the took the right path. 
And the route is still calculated right before packet transmission.

> Other things :
> what mean the rtdm_device fileds :
> " device_name" 

That field is only used for named devices, like serial drivers or any 
special devices like the TDMA discipline interface. It has no meaning 
for protocol drivers like RTnet's UDP/IP and packet socket implementations.

> "peripheral_name"
> "driver_name"
> 

Pure informational stuff, only used for browsing RTDM devices via /proc 
so far.

> Can'I use any on eof them with the function get_dev_by_name .
> 

Nope, get_dev_by_name resolves names like "rteth0" or "rtlo".

What are you actually planning? Likely there is a different way to 
achieve it.

Jan

Re: [RTnet-developers] multicast support

[Amine El h. <am...@an...>]

Hi 

It is possible to get rtnet_device pointer form rtsocket pointer.
for example    struct rtnet_device *rtdev= xxxxx(struct rtsocket sk);
I can't find any way to do that 
Other things :
what mean the rtdm_device fileds :
" device_name" 
"peripheral_name"
"driver_name"

Can'I use any on eof them with the function get_dev_by_name .

think

Amine

Re: [RTnet-developers] multicast support

[Jan K. <ki...@rt...>]

Amine El hedadi wrote:
> Linux use timer in muticast to excute periodically a function to keep session 
> between switch & computer whitch need multicast flux , so it use one timer by 
> multicast connection(IGMP protocol). this work not need a real time 
> behaviurs, so why I have asked about using the same timer in RTNET framework. 
> I can use  real periodic task but I don't need real time behaviors in this 
> case, may be  rt task with low priority.
> 

I see, my knowledge about multicast has just been proven to be rather 
limited :).

The point with a Linux timer is not that it is too unreliable for this 
task (BTW, about what period dimensions are we talking here?), the 
problem is that you cannot issue a packet from non-RT Linux context 
(IRQ, tasklet, process, whatever). So you need at least a low prio 
real-time task (one step above Linux, see how RTcfg works WRT timers 
e.g.) to transmit this keep-alive stuff.

I guess you have to transmit those packets only if no other traffic was 
present on the specific multicast channel (MAC address), haven't you? 
Isn't it possible to code this feature into the application? I think it 
knows best when it last received or transmitted some data. Or am I just 
missing some important characteristics of the IGMP protocol?

In any case, I think the IGMP part, which seems to be required when it 
comes to IP multicasting, is part of step 2, while the first step should 
be to get the low level multicast support (Ethernet layer) working. Or 
does this appear to be too tightly coupled for you?

Jan

Re: [RTnet-developers] multicast support

[Amine El h. <am...@an...>]

Linux use timer in muticast to excute periodically a function to keep session 
between switch & computer whitch need multicast flux , so it use one timer by 
multicast connection(IGMP protocol). this work not need a real time 
behaviurs, so why I have asked about using the same timer in RTNET framework. 
I can use  real periodic task but I don't need real time behaviors in this 
case, may be  rt task with low priority.

Amine
> Amine El hedadi wrote:
> > Hi
> > It is possible to use Linux timer in RTNET framework?
> > Linux use them for multicast support.
>
> Generally not - as long as not just device setup, reconfiguration, or
> shutdown is involved. You would have to use equivalent RTAI features.
>
> What are these timers precisely used for? Right now, I cannot imaging
> what kind multicast related job needs timing. Shouldn't it "just" be
> programming some additional MAC addresses (or address hash values) the
> card shall listen to? Or are those timers required for higher layers?
>
> Jan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> RTnet-developers mailing list
> RTn...@li...
> https://lists.sourceforge.net/lists/listinfo/rtnet-developers

RE: [RTnet-developers] multicast support

[Zhang Y. <y.z...@st...>]

Linux timer is not real-time, but rtai timer is ok. 
See the rati tasklet module. 

Yuchen 

> -----Original Message-----
> From: rtn...@li... 
> [mailto:rtn...@li...] On 
> Behalf Of Amine El hedadi
> Sent: Wednesday, June 01, 2005 11:40 AM
> To: rtn...@li...
> Subject: Re: [RTnet-developers] multicast support
> 
> Hi
> It is possible to use Linux timer in RTNET framework?
> Linux use them for multicast support.
> 
> Amine.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into 
> your own Applications - visit 
> http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> RTnet-developers mailing list
> RTn...@li...
> https://lists.sourceforge.net/lists/listinfo/rtnet-developers
> 

Re: [RTnet-developers] multicast support

[Jan K. <ki...@rt...>]

Amine El hedadi wrote:
> Hi 
> It is possible to use Linux timer in RTNET framework?
> Linux use them for multicast support.
> 

Generally not - as long as not just device setup, reconfiguration, or 
shutdown is involved. You would have to use equivalent RTAI features.

What are these timers precisely used for? Right now, I cannot imaging 
what kind multicast related job needs timing. Shouldn't it "just" be 
programming some additional MAC addresses (or address hash values) the 
card shall listen to? Or are those timers required for higher layers?

Jan

Re: [RTnet-developers] multicast support

[Amine El h. <am...@an...>]

Hi 
It is possible to use Linux timer in RTNET framework?
Linux use them for multicast support.

Amine.

[RTnet-developers] Re: Problem with sendto

[Amine El h. <am...@an...>]

can you send me your makefile , i have some problem to link your application.

> thanks for your help, I send you my real code, because before I send
> only the function
> My program send and receive the packet with 2 ethernet cards in the PC.
> But I've also problem with the recvfrom, if I use this function the
> system crash! and I don't know why...
>
> If you like I send you my Makefile
> Thanks
>      Nicol@

Re: [RTnet-developers] multicast support

[Amine El h. <am...@an...>]

think you Jan for this explanations.
Now im traying to build a mark of linux multicast working. So to port it to 
rtnet , i will need some informations about RTNET archetecture . that will 
help to do it cleanly and correctly.

Amine

On Tuesday 24 May 2005 20:58, you wrote:
> Amine El hedadi schrieb:
> > I need to use rtnet for audio & video streaming , so i want to add
> > support for multicasting to rtnet.
> > Now im trying to understand the working of mutlicasting in linux kernel,
> > and i look for the way to port it to rtnet.
> > So if you have any propositon to do that , please let me know.
>
> Beyond the aspect of how to manage rtskbs (RTnet's real-time packet
> buffers) for which I already posted a mail thread link, you should
> certainly first start with multicast at Ethernet level. First, you need
> support in at least one driver. Pick one and extend (or re-enable) its
> multicast features. Watch out for potentially required hard real-time
> synchronisation means between transmission/reception handlers and
> multicast manipulation functions. Feel free to ask what to use or how
> certain things work inside the driver.
>
> Next, it's likely useful to add the required API to the packet socket
> interface (stack/packet/af_packet.c). That API has to provide means for
> registering to and detaching from a multicast group at Ethernet protocol
> level. Check Linux man pages etc. for documentation.
>
> Later, the integration in RTnet's UDP/IP stack can be addressed. Here,
> the question needs to be answered how to map the multicast IP address on
> Ethernet MAC addresses. Not sure right now how this happens in normal
> networks, but I guess a static configuration is likely the easiest way
> for a first approach in RTnet.
>
> Looking forward to further discussions! I'm also interested in learning
> more about multicast implemenation and potential hard real-time issues.
>
> Jan

Re: [RTnet-developers] multicast support

[Jan K. <jan...@we...>]

Jan Kiszka schrieb:
> ...
> Later, the integration in RTnet's UDP/IP stack can be addressed. Here, 
> the question needs to be answered how to map the multicast IP address on 
> Ethernet MAC addresses. Not sure right now how this happens in normal 
> networks, but I guess a static configuration is likely the easiest way 
> for a first approach in RTnet.
> 

And if I had thought about this a second longer, I would have remembered 
that RTnet's routing system already provides all what's required for 
that static mapping.

Jan

Re: [RTnet-developers] multicast support

[Jan K. <jan...@we...>]

Amine El hedadi schrieb:
> I need to use rtnet for audio & video streaming , so i want to add support for 
> multicasting to rtnet.
> Now im trying to understand the working of mutlicasting in linux kernel, and i 
> look for the way to port it to rtnet.  
> So if you have any propositon to do that , please let me know.
> 

Beyond the aspect of how to manage rtskbs (RTnet's real-time packet 
buffers) for which I already posted a mail thread link, you should 
certainly first start with multicast at Ethernet level. First, you need 
support in at least one driver. Pick one and extend (or re-enable) its 
multicast features. Watch out for potentially required hard real-time 
synchronisation means between transmission/reception handlers and 
multicast manipulation functions. Feel free to ask what to use or how 
certain things work inside the driver.

Next, it's likely useful to add the required API to the packet socket 
interface (stack/packet/af_packet.c). That API has to provide means for 
registering to and detaching from a multicast group at Ethernet protocol 
level. Check Linux man pages etc. for documentation.

Later, the integration in RTnet's UDP/IP stack can be addressed. Here, 
the question needs to be answered how to map the multicast IP address on 
Ethernet MAC addresses. Not sure right now how this happens in normal 
networks, but I guess a static configuration is likely the easiest way 
for a first approach in RTnet.

Looking forward to further discussions! I'm also interested in learning 
more about multicast implemenation and potential hard real-time issues.

Jan

[RTnet-developers] multicast support

[Amine El h. <am...@an...>]

I need to use rtnet for audio & video streaming , so i want to add support for 
multicasting to rtnet.
Now im trying to understand the working of mutlicasting in linux kernel, and i 
look for the way to port it to rtnet.  
So if you have any propositon to do that , please let me know.


Amine 

[RTnet-developers] Re: [RTnet-users] timer support in RTnet?

[Jan K. <ki...@rt...>]

Zhang Yuchen wrote:
>  AFAIC, one constraint of the TDMA worker approach is lacking of
> flexibility, i.e. new timer can not be inserted before the next wakeup.
> Of course, flexibility is not really necessary for TDMA scenario, since all
> the time slots are relatively fixed: when a new slot is added, the earlist
> time for it to take place is in next cycle. (Pls Fixme if I am wrong:)).

Yep, the TDMA worker has been designed specifically for the TDMA 
protocol. And this protocol is rather static, although you can change 
the slot configuration during runtime the way you described it. But as 
one cycle more or less does not matter for the reconfiguration which is 
typically user-triggered, thus inherently non-rt, there was no need for 
a more "flexible" timer configuration.

> But in general scenario, it is possible that a new timer has a wakeup need
> which is closer in time than all previous ones. Like in FireWire, timered
> queue is for mix of bus reset and transaction retry or failure detection. 
> Also the queue can be empty.
> 

The timer pattern I typically use with RTAI is always based on tasks: 
one task per timer. In your case, you could consider creating multiple 
tasks instead of only one as TDMA or also RTcfg does. Then you just have 
to take care for synchronising their access to common resources 
appropriately.

> One solution (after brainstorming): we use a realtime task similiar to
> "TDMA-work", and assume the timeout for all asynchronous transactions, i.e.
> between resquest and response, are of the same length, so it is not possible
> to jump the queue (bus reset is not taken into account here, since it is
> really real-time killing). Ok, when the queue is empty, i.e. no asynchronous
> transaciton is going on, the real-time task get blocked on a semaphore
> instead of sleep on timer interrupt. Everytime a new timer is added, the
> queue length should be checked, in case it is zero, a "up" on the semaphore
> should be done. 
> 

Also an option.

Using the timer mechanism RTAI provides (e.g. the rt_alarm_xxx API under 
fusion) is more light-weight than tasks of course, but you have to 
consider that the timer handlers are - by design - executed at least 
under scheduling lock, often (fusion, don't know about classic RTAI) 
also with IRQs turned off. So you shouldn't do much work here...

Jan

[RTnet-developers] RE: [RTnet-users] timer support in RTnet?

[Zhang Y. <y.z...@st...>]

 AFAIC, one constraint of the TDMA worker approach is lacking of
flexibility, i.e. new timer can not be inserted before the next wakeup.
Of course, flexibility is not really necessary for TDMA scenario, since all
the time slots are relatively fixed: when a new slot is added, the earlist
time for it to take place is in next cycle. (Pls Fixme if I am wrong:)).
But in general scenario, it is possible that a new timer has a wakeup need
which is closer in time than all previous ones. Like in FireWire, timered
queue is for mix of bus reset and transaction retry or failure detection. 
Also the queue can be empty.

One solution (after brainstorming): we use a realtime task similiar to
"TDMA-work", and assume the timeout for all asynchronous transactions, i.e.
between resquest and response, are of the same length, so it is not possible
to jump the queue (bus reset is not taken into account here, since it is
really real-time killing). Ok, when the queue is empty, i.e. no asynchronous
transaciton is going on, the real-time task get blocked on a semaphore
instead of sleep on timer interrupt. Everytime a new timer is added, the
queue length should be checked, in case it is zero, a "up" on the semaphore
should be done. 

More brainstorming or correction are surely welcome:)

Yuchen



-----Original Message-----
From: rtn...@li...
[mailto:rtn...@li...] On Behalf Of Jan Kiszka
Sent: Thursday, May 19, 2005 4:12 PM
To: Zhang Yuchen
Cc: rtnet-users; 'Orlic, B.'; P.M.Visser
Subject: Re: [RTnet-users] timer support in RTnet?

Hi Yuchen,

> HI, Jan and others,
> 
> in the current stage of RT-FireWire development, I am facing the 
> problem of using a timer for scheduled re-transaction and bus reset issue.
> In Linux 2.6 FireWire stack, this is supported by the nice timered 
> workqueue of kernel2.6. Now, I am seaching for a easiest approach to 
> build or reuse a timered workqueue in RTAI for the RT-FireWire stack. 
> Actually, the same problem also exists in Ethernet. If I am correct, 
> the timer is initialized in Ethernet device driver for each network 
> device (I only checked rt_eepro100.c), but in RTnet, the timer is 
> still based on the linux timer support. So I am wondering if we need a 
> timered workqueue extension like in Linux 2.6 to RTAI.
> 

The RTnet's Ethernet drivers do not contain any timers. Their non-rt
ancestors contain some for media status monitoring, but this is switched off
for the real-time use-case.

The timer required to manage the Ethernet media access based on TDMA is
created as a real-time task. Take a look at the implementation of
tdma_worker in

http://www.rts.uni-hannover.de/rtnet/lxr/source/stack/rtmac/tdma/tdma_worker
.c

It's a big loop executing the currently scheduled job on a TDMA instance
(one instance per managed Ethernet device). Such a job can be to wait on the
synchronisation frame or to delay the execution until the next transmission
time slot arrives and then issue a pending packet.

There are generally several ways to reach a goal. ;)

Jan


PS: Better to discuss on rtnet-developers ;)


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the
first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
_______________________________________________
RTnet-users mailing list
RTn...@li...
https://lists.sourceforge.net/lists/listinfo/rtnet-users

Re: [RTnet-developers] patch for the natsemi driver

[Jan K. <ki...@rt...>]

Petr Grillinger wrote:
> Hello,
> 
> I found a small bug in the natsemi driver. The function is called only 
> when the device is closed, so it is quite unlikely to cause many 
> problems, but still there is the patch :-)
> 
> (the diff was made vs. rtnet 0.8.0 version)
> 
> Petr Grillinger
> 

Thanks for the patch. Just applied to SVN. Obviously some bug that was 
imported from the older original linux version of the natsemi driver.

Jan

[RTnet-developers] patch for the natsemi driver

[Petr G. <gri...@vm...>]

Hello,

I found a small bug in the natsemi driver. The function is called only 
when the device is closed, so it is quite unlikely to cause many 
problems, but still there is the patch :-)

(the diff was made vs. rtnet 0.8.0 version)

Petr Grillinger

[RTnet-developers] Small changes in RTOS abstraction layer

[Jan K. <jan...@we...>]

Hi all,

in order to make correct use of IRQ handling functions stacked upon 
RTAI/fusion's Xenomai nucleus (e.g. the functions of the rtai_native 
skin), the RTOS abstraction layer had to be changed slightly.

RTAI/fusion expects to use a handle structure for referring to requested 
IRQs, while old RTAI and also Linux only needed the IRQ number. 
Therefore, I modified rtnet_sys_xxx.h appropriately. Unfortunately, also 
the drivers had to be changed. I already did this for any driver execept 
the 3com and the still broken PPC drivers. See README.drvporting for 
details - sorry, it's still a quite unordered list.

Yuchen, you don't need to hurry porting these changes also to the 
firewire branch - at least as long as it is 2.4-only, fusion will not 
run with it anyway.

Jan