Hi,
the ethernet emulation on Firewire (eth1394) has been ported to RTnet. The
module stack consists of eth1394_rt.o, ieee1394_rt.o and ohci1394_rt.o.
Another module, rtos_tasklet_scheduler.o needs also to be loaded, to make
sure the tasklets triggered in the top half of interrupt handlers are
executed in real-time manner.
Absolutely amazing! And you even managed to complete this part right before Christmas vacation - I think you deserve some free time now ;)
So far, the round trip test can be run on Firewire. The results are compared with ethernet. With a low packetsize, the average round trip latency on Firewire is close to that on ethernet. But with a high packetsize, like 1400, Firewire shows its stronge point: the average is almost 100us less than on ethernet. This is because of the high data payload in Firewire
Mmh, I'm not that convinced yet that there is so much more overhead with Ethernet, especially when packets get larger. Did you actually compared 100 MBit/s Ethernet with 100 MBit/s Firewire? Or was it 400 MBit/s???
packet. In Firewire asyn. transmission, depending on the hardware, the
payload can be 512, 1024, 2048, corresponding to the speed: 100mb/s,
200mb/s, 400mb/s. It can even be higher in 1394b. The chip in my setup
supports 400mb/s, i.e. 2048 bytes per packet. So another thing noteworthy
is, on a Firewire chip supporting 2048 bytes per packet (which is quite
common in the market), the mtu for eth1394 can be as high as 2044 bytes,
subtracting encapsulation header for ipv4 on 1394. This means eth1394
provides a higher payload than normal ethernet (1500), but the question is
how can we use this high payload, in which occasions?
If we do not have some hidden bugs, RTnet should use larger MTUs than 1500 without any problems. Just try to set a different value in your eth1394 rtdev structure and watch what happens with big IP packets. :)
The next step could be using Firewire directly in real-time occasion,
bypassing the ip protocol. To achieve this, there will be benefits, one is
to increase payload, another is to save some processing power from the
protocol conversion between ip and 1394. For this, I would like to have your
suggestions: can I relate this to the rtdm framework, how?
Did you already take a look at the AF_PACKET protocol interface? It can be used with Ethernet to bypass the IP layer, and it should directly work with Firewire as well (if there are no hidden bugs...). You may also test the corresponding interface under standard Linux and compare the behaviour with RTnet. Any differences would require closer examination and probably a fix.
Jan
smime.p7s
Description: S/MIME Cryptographic Signature
