You don't describe your test set up at all, but my team did a lot of

testing of MANET protocols under stress (we used TBRPF) turned up a

couple of conditions that gave us the same reactions.<br>

<br>

1) If you congest the radio link you're going to start dropping routing

protocol packets, drop enough and the route goes away.  This is

especially a problem if your ingress ports are very fast - we tested on

266MHz Geodes (Soekris 4801) with 100Mb/s full duplex Ethernet feeding

802.11a/b/g radios.  On a good day we would get maybe 20Mb/s

through the radio, so ignoring a lot of stuff, right off the bat you

can see that a lot of packets aren't going to make it through the radio.<br>

<br>

2) If you're using low powered hardware (i.e. Atheros 802.11a running

on anything less than 600-800MHz) we also encountered a problem where

under the load of a full-bore Ethernet that the kernel spent all it's

time throwing packets away and *not* giving time to the routing daemon

running in user space.<br>

<br>

The above can be greatly aggravated by your test equipment - we used

Ixia which can do all manner of mean things like violate interframe

spacing to acheive utilization > %100.  Doing this to an

ether->802.11 link was very hard on the routing protocol which was

sending relatively few packets compared to the test traffic.  We

got the best results by running the traffic generator at some level

less than the expected throughput of the 802.11.<br>

<br>

This is a little unrealistic in that you can't really control the

traffic, except maybe by implementing the source quench message (I

don't know if Linux can do that).<br>

<br>

Testing throughput is also complicated by the "tuning" of the protocol

parameters.  So a network tuned for static stations would perform

better under heavy load than one tuned for high mobility.  When I

was looking for good throughput numbers/characteristics I just set the

protocol to be very unrepsonsive.  Networks tuned for high

mobility are almost always going to suffer from instability under load

- that's just the way things work.<br>

<br>

Ok, I just checked and you say you're using two ethernet interfaces, I

think the discussion still holds, but not as pronounced as when there's

a great disparity in speed between the interfaces.<br>

<br>

dave c<br><br><div><span class="gmail_quote">On 8/31/05, <b class="gmail_sendername">Chang Jiang</b> <<a href="mailto:changjiang@research.nec.com.cn">changjiang@research.nec.com.cn</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hi all,<br><br>When I measure the end-to-end traffic rate of terminals in my ad-hoc network<br>with OLSR routing, I found the traffic rate suffers intermittent<br>interruption. The phenomenon disappeared after I replace the OLSR routing

with static routing (add route in the routing table). What's the reason? Thanks. ============= Testbed: ----------------- Two nodes (with 2 NIC -eth0,eth1): Node1, Node2 eth1 in each node runs the olsrd.

<br>eth0 works as the accessing NIC.<br><br>Two terminals: terminal_1, terminal_2<br>terminal_1 access to the eth0 of node 1;<br>terminal_2 access to the eth0 of node 2;<br>-----------<br>Software<br>1. Redhat Linux 9.0<br>

2. olsrd 0.4.9<br>------------------------------<br>Topology:<br><br>terminal_1<--->|eth0 eth1|<------>|eth1 eth0|<------>terminal_2<br>                              Node1                

Node2<br><br>_______________________________________________<br>olsr-dev mailing list<br><a href="mailto:olsr-dev@olsr.org">olsr-dev@olsr.org</a><br><a href="https://www.olsr.org/mailman/listinfo/olsr-dev">https://www.olsr.org/mailman/listinfo/olsr-dev

</a><br></blockquote></div><br>