Thanks Gary. Please note my responses. > On Mon, 2005-09-12 at 14:32 -0700, [EMAIL PROTECTED] wrote: >> Indeed, it was cache enabling problem. >> >> Here is the new numbers which are getting closer but still needs some >> work: >> >> Linux: max 26,000 packets (60 bytes) per second (single burst) with no >> drops >> >> eCos: max 23,500 packets (60 bytes) per second (single burst) with no >> drops >> > > This is good to know. Obviously there are some things that could be > worked on, but it's quite close (and given the differing strategies, > not hard to imagine) > >> I DO HAVE A SETUP ISSUE which I need help. I want to route packet coming >> in from IP address: 192.168.1.80 to eth0 (IP ROUTE) to eth1 and eth1 to >> route to its destination ip: 192.168.2.80. As you see the purpose is to >> test performance of my driver and eCos vs Linux by SmartBits. Here is an >> snap-shot of my eCos route table: > > What makes you think this should happen automatically? What have you > done to tell eCos that packets that come in on the 192.168.1.x network > should automatically flow through to the 192.168.2.x network?
Isn't this just pure IP routing table look up and forwarding to proper interface? 1) source 192.168.1.80 prepare a packet with mac address of eth0 and IP address of target (192.168.2.80) and sends it 2) eth0 receives the packet and passes it to IP layer, since the IP address does not match the ip address of eth0, routing table should be consulted to deliver the packet to proper interface 3) eth1 gets the packets and sends it to its target. Shouldn't eCos do this, am I mistaken and not enabled a feature in eCos? Here is a dump of routing table: Routing tables Destination Gateway Mask Flags Interface 0.0.0.0 192.168.1.8 0.0.0.0 UG eth0 127.0.0.0 127.0.0.1 255.0.0.0 UG lo0 127.0.0.1 127.0.0.1 U lo0 192.168.1.0 192.168.1.0 255.255.255.0 U eth0 192.168.2.0 192.168.2.0 255.255.255.0 U eth1 Arp table IP addr MAC addr Flags ---------------------------------------------- 192.168.1.8 02:10:12:01:00:08 UHCL 192.168.1.80 00:00:00:00:00:01 UHC 192.168.2.8 02:10:12:01:00:09 UHCL 192.168.2.80 00:00:00:00:00:02 UHC > > I'm not sure that this would work with the BSD stack without bridging > support (which has never been ported to the latest stack) > > -- > ------------------------------------------------------------ > Gary Thomas | Consulting for the > MLB Associates | Embedded world > ------------------------------------------------------------ > -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
