Jeroen Willems wrote:
Hi,I set up a scenario to test the speed of rtnet but my results aren't satisfying. Set up: 1. Notebook (#1) - IBM T42, Linux 2.6.19.7, Xenomai 2.3.1, RTNet 0.9.9, driver rt_e1000 2. Notebook (#2) - ASUS A6000, Linux 2.6.19.7, Xenomai 2.3.1, RTNet 0.9.9, driver rt_r8169 Because starting up in KDE mode gave IRQ conflicts, I had to use "CTRL-F1" (I don't know how I have to call it).
One may call it text mode.
I used the following code to startup RT-Net in CTRL-F1 mode (for #1) -- ifconfig eth0 down rmmod e1000 insmod /usr/local/rtnet/modules/rtnet.ko insmod /usr/local/rtnet/modules/rtipv4.ko insmod /usr/local/rtnet/modules/rtpacket.ko insmod /usr/local/rtnet/modules/rt_e1000.ko /usr/local/rtnet/sbin/rtifconfig rteth0 up 10.0.0.1 /usr/local/rtnet/sbin/rtroute add 10.0.0.2 "MAC-Adres" dev rteth0 -- #1 runs 2 programms, 1 in CTRL-F1, the packet sender. And 1 in CTRL-F2, the packet receiver. #2 runs 1 programm which rebounds the packets. The programms are based on frag-ip and are in the attachment. I got the following results with sending 1000 packets which have a size of 1514+10 bytes. Period [ns] Mean [ns] 50000 130189.90 100000 122516.10 150000 108576.57 250000 108763.02 500000 110926.49 The time is measured by making a timestamp on send time and comparing this timestamp with the timestamp when received on the same notebook. I don't know why the large times are caused.
Well, "large" is relative. We are talking about ~110 us full round-trip time for 1.5 KB data. Already ~25 us is pure transmission time. At least a bit data is shuffled back and forth (to/from the NIC and inside the stack). And then there is quite some software involved. Depending on your system configuration and the hardware performance, such numbers can be reasonable. At least they are not orders of magnitudes too large.
My First question is, what could have caused these great time values? Second is, does anyone else have some test results and scripts so I can compare the results and set up.
To get a better picture of what contributes to the latency, you may want to try the I-pipe latency tracer (check Xenomai homepage for details - at this chance you may also want to update your system). It will add a bit more latency to this, but it can give a fairly deep insight into the code paths on both sides. And maybe it reveals inefficiency in some parts due to suboptimal configuration or some bug or whatever. E.g., I can't tell much about the efficiency of the rt_r8169.
If something is unclear feel free to ask for clarification Thanks in advance, Jeroen
Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
