• TourNament

Tournament rules

* For the tournament we will set up a single ad-hoc cell consisting of ~75 nodes outdoors. Most devices will have a single radio interface, but we will set up a subset of routers with two interfaces if the hardware is available.

* The systems we use are CPU and memory-constraint. Since it is not feasible to set up a LAN to all nodes on the site we have to run synchronized test programs, interrupt them and collect the data. Two competing protocols will run simultaneously during each challenge, so both participants will have a comparable radio environment. We will measure memory consumption, CPU load, time to establish end-to-end routes, existence of routes which should be there according to layer 2 reachability, routing performance (round-trip latency, throughput, packet loss), protocol overhead, convergence speed and detect and measure the occurance of routing loops. A tentative/sample list of tests is here. Each performance property will be marked with points to get a overall rating. The ratings and measurement results for each day will be published on this web site. If all goes well on the technical side we can repeat the challenges, until the day of the final tournament. So developers have the opportunity to improve their code, settings, fix bugs.

* Mesh protocol implementations must be open source and work with OpenWrt Linux (probably on Atheros (Mips 4K) platform ?). Source of the actual implementation must be available for code review. (Just for clarification: We don't expect to see anyone trying to use unfair tricks.)

* All you can win is a good feeling and a good reputation. You should later memorize the event as fun and joy even if you don't win. There is no prize (maybe we come up with a symbolic prize but nothing really valuable in terms of money).

Topology and tests

Here are some tests that could be performed to see which protocol wins the battle...

Test (a) - Linear topology

* Step 1. Place the nodes.

Use these power columns, if available: 22-23-30-29-16-13-11 or 1-2-4-5-6-7-10-11. Otherwise use the batteries to replace the unavailable columns. It is important that the nodes are on a line as much as possible and that each node can communicate with at least two nodes on each side. To check the communication you can check that ping is successful at least half of the times, or iwconfig returns a measured signal of -80 dBm or more. The two sets above should guarantee that.You can also add some battery-powered nodes along the line.

* Step 2. Generate and measure the traffic. Connect a notebook at each of the end nodes (ex: 22 and 11, or 1 and 11; bridged, not routed). So you can generate traffic without increasing CPU load of foneras. Run some script/command/whatever to send traffic from one notebook to the other. For example MGEN, iperf, etc.It is important that most (almost all) of the traffic is unidirectional (e.g. UDP packets). There might also be some "control" traffic, such as ping or traceroute to record the routes. Use three sizes of packets: big (8192 bytes), medium (1024), and small (128) to test under different packet sizes (this might have an influence on the link behaviour). Run some script/command/whatever on the receiving notebook to record the "instantaneaous" throughput (an average over one-second intervals should do; I think iperf does that; other tools are MGEN, wireshark, etc). Note: DO record the instantaneaous throughput on a log file! Start with a low packet rate, and increase it until the throughput does not grow any more. For example, start with 100 pkt/s, then go to 200, 300, etc. You can obviously make a script that automatically increases the rate every, say, 30 seconds. Finally, repeat by inverting the source and destination notebooks.

* Step 3. Repeat with another protocol Try to put the nodes exactly in the same place and with the same orientation. The protocol that gets the highest aggregate throughput (in both directions) wins.

Test (b) - Network capacity

* Step 1. Place the nodes on the circled columns (or just place as many nodes as possible ;-)). Also place a battery-powered node on the beach (blue triangle)(on the point of the last boat should do). The node on column 5 should be raised above the metallic net.

* Step 2. Generate and measure the traffic (similarly to previous test). Connect two notebooks at two edge nodes (ex: 21 and 11). Run some script/command/whatever to send traffic from one notebook to the other and some script/command/whatever on the receiving notebook to record the throughput (see above). You can test with both unidirectional (e.g. UDP packets) and bidirectional traffic (e.g. TCP). For UDP you can use three sizes of packets: 8192, 1024, and 128. Start with a low packet rate, then add more source destination pairs, until the received throughput (by all dest nodes) does not grow any more (or until you have no more src-dst pairs ) For example, some more pairs could be: 18-31, 1-15, 9-33, 25-6, 11-26 (in this order). If the src-dst pairs are not enough to saturate the network, just increase the packet rates on the various sources, one at time (i.e. increase one, check throughput, after say 30 seconds increase second, check, and so on...). For example, start with 100 pkt/s, then go to 150, 200, etc.

* Step 3. Repeat with another protocol Try to place the nodes exactly in the same place and with the same orientation. The protocol that gets the highest aggregate throughput (in both directions) wins.

Test (c) - Recovery

* Step 1. Place the nodes as in the previous test.

* Step 2. Generate and measure the traffic (similarly to previous test). Connect two notebooks at two edge nodes (ex: 11-33, or 9-21 - but you can also test both pairs ). Run some script/command/whatever to send traffic from one notebook to the other and some script/command/whatever on the receiving notebook to record the throughput. If you succeed on recording on smaller intervals is better (e.g. 500 ms, or 200 ms; but don't go below 200 ms, as I expect you won't have very stable measures). Test with unidirectional traffic (e.g. UDP packets). One packe size should be enough (1024?). Start with a low packet rate, and increase it until the registered throughput does not grow any more (similarly to test a). Then find the route that is currently followed (ping, traceroute, etc), and turn off one of the intermediate nodes (for example, if the route is 9-13-15-29-21, turn off node 15; a harder test is turn off both 15 and 16). Then see at the receiving node how long it takes to resume the connection. You should notice a gap in the received throughput, or a momentary lowering (but if the protocol is very fast probably you won't notice anything ;-)). Of course, the smallest the interval for recording the throughput, the finer the gap measure. Note: if you cannot see what the route is because ping/traceroute doesn't work, try lowering the load on the network by reducing a bit the packet rate, until you can get the route (can also record the route at the beginning, when the traffic is low).

* Step 3. Repeat with another protocol Try to place the nodes exactly in the same place and with the same orientation. The protocol that gets the smallest throughput gap (or the lowest lowering) wins.

Node map