Battlemesh logo
  • Comments
  • Edit
  • Menu
    • Navigation
    • RecentChanges
    • FindPage
    • Local Site Map
    • Help
    • HelpContents
    • HelpOnMoinWikiSyntax
    • Display
    • Attachments
    • Info
    • Raw Text
    • Print View
    • Edit
    • Load
    • Save
    • Edit SideBar
  • Login

Navigation

  • RecentChanges
  • FindPage
  • PastEvents
  • ContactUs
  • HelpContents

Upload page content

You can upload content for the page named below. If you change the page name, you can also upload content for another page. If the page name is empty, we derive the page name from the file name.

File to load page content from
Page name
Comment
tën plüs twö minüs 3?

  • BattleMeshV6
  • PlannedTests

BattleMeshV6 Tests

This page describes the planned tests for BattleMeshV6. For the actually performed tests, please see AcutalTests.

Contents

  1. BattleMeshV6 Tests
    1. General Rules
    2. Tests
      1. Basic Stats
      2. Be Quick or Be Stable Test
        1. Steps
        2. Goals
        3. References
      3. The Channel Surfer Test
        1. Steps
        2. Goal
      4. Convergence Time Test
        1. Steps
        2. Goal
      5. Don't Cross the Streams Test
        1. Steps
        2. Goal
        3. References
    3. Contacts / Discussion

General Rules

  • same routing protocol revision and configuration for every test
  • routing protocols are tested altogether
  • no points, just results and a final analysis

Tests

Basic Stats

  • 54Mbps multicast rate
  • count the number of nodes that each routing protocol can see in its topology
  • watch the resources used when the network is unloaded

Be Quick or Be Stable Test

To be performed on a subset of the nodes.

 +----+
 | L1 |-----(A) : : : : : : (B)
 +----+      :       r1      |
             :               |
             :               |
             : r2            |
             :               |
             :               |       +----+
            (C)-------------(D)------| L2 |
                                     +----+
  • L1, L2: laptops
  • A, B, C: wireless nodes
  • link A-B uses association rate r1
  • link A-C uses association rate r2
  • r2 > r1

  • - and | are cables
  • : are wireless links

Steps

5x for each protocol

  1. perform a continuous traceroute (mtr or whatever) from L1 to L2
  2. load the network with UDP (iperf or whatever) from L1 to L2
  3. start a 11 minutes download from L2 to L1
  4. see how many times (if any) the route flaps in 11 minutes
  5. see if the routing protocol prefers the slow or the fast route

Goals

Check the stability of the routing protocol, and if the metric is effective.

References

  • http://www.youtube.com/watch?v=fZLv2G0Hhn4

The Channel Surfer Test

To be performed on a subset of the nodes.

 +----+
 | L1 |-----(A)
 +----+      :
           x :
             :       x
            (B) : : : : : : ( )     +----+
            ( ) : : : : : : (C)-----| L2 |
                     y              +----+
  • L1, L2: laptops
  • A: node set on channel x
  • B, C: multi-radio nodes set on channels x and y
  • - and | are cables
  • : are wireless links

Steps

only 1x for each protocol

  1. perform a continuous traceroute (mtr or whatever) from L1 to L2
  2. load the network with TCP (iperf) from L1 to L2 for 21 minutes
  3. sleep until the end of the iperf stream
  4. see for which fraction of the time the routing protocol chooses the best route (L1->A->B->C->E->L2)

  5. see the amount of transferred bytes

Goal

See if the routing protocol prefers the channel-changing route, by design or by just because is the best path.

Convergence Time Test

To be performed on the whole mesh.

           .~.~.~.~.~.~.~.~.~.~.~.       
 +----+   (                       ) : (GW1)-+
 | L1 | :(                         )        |   
 +----+   (                       )         |   +----+
         (                         )        +---+ L2 |
          (                       )         |   +----+
         (                         )        |
          (                       ) : (GW2)-+
         (        MESH CLOUD       )     
          .~.~.~.~.~.~.~.~.~.~.~.~.
  • GW1 and GW2: gateways announcing the address of L2

  • The metric from L1 to GW1 is significantly better than the metric from L1 to GW2

Steps

repeat 3x for each protocol

  1. traceroute from L1 to L2 and verify that the path goes through GW1

  2. start pinging from L1 to L2

  3. start a continuous traceroute (mtr or whatever) from L1 to L2

  4. turn off GW1

  5. count the number of pings from the first lost ping to the first subsequent successful ping
  6. after 2 minutes from its turning off, turn back on GW1 and start a stopwatch

  7. measure the time needed to the network to use GW1 again

Goal

Just convergence time.

Don't Cross the Streams Test

To be performed on the whole mesh

 +----+            .~.~.~.~.~.~.~.~.~.~.~.            +----+
 | L1 |-----(A) : (                       ) : (C)-----| L3 |
 +----+          (                         )          +----+
                  (                       )
                 (          MESH           )
                  (         CLOUD         )
 +----+          (                         )          +----+
 | L4 |-----(D) : (                       ) : (B)-----| L2 |
 +----+          (                         )          +----+
                  .~.~.~.~.~.~.~.~.~.~.~.~.
  • L1, L2, L3, L4: laptops
  • A, B, C, D: edge wireless nodes

Steps

only 1x for each protocol

  1. start, at the same time:
    1. a 21 minutes TCP stream between L1 and L2
    2. a 21 minutes TCP stream between L3 and L4
  2. sleep for 21 minutes
  3. measure the total number of bytes transferred

Goal

See if the routing protocol can choose the paths for the two streams that maximizes throughput.

References

  • http://www.youtube.com/watch?v=jyaLZHiJJnE

Contacts / Discussion

  • Battlemesh-test mailing list: http://ml.ninux.org/mailman/listinfo/battlemesh-test

  • MoinMoin Powered
  • Python Powered
  • GPL licensed
  • Valid HTML 4.01