Mesh test at scale

[Javier Cardona]

Hi Brian,

2009/3/5 Brian DeLacey <bdelacey at gmail.com>:
> I have an opportunity to install mesh points on 16 - 25 fresh machines in a
> data center (this weekend).

That's great!  That's bigger than our testbed, so I'm eager to see your results.

> Are tests worth running at this scale? What functionality should the tests
> cover?

Certainly.  Some interesting tests (some require some
coding/instrumentation, though)

1.  Coverage,RTT as a function of the number of peers.

Set the maximum number of peers on each node to N (mesh_max_peer_links), N > 1.
Set the mesh ttl (mesh_ttl) to be equal or higher than the total
number of nodes in your mesh.
Run a script on each node to ping all other nodes in a round robin fashion.
Record the  round trip time and losses.
Record the avg. number of hops at reception (this requires adding
instrumentation code to the stack).

As N decreases, longer routes will have to be used between any two
nodes in the mesh.  This will stress route discovery.

2.  Path recovery time.

Using iw dev mesh station $HW_ADDR set plink_action block, force
multi-hop routes through known nodes.
Ping through a multihop path.
Measure the effects in the RTT of breaking paths.

3.  Throughput as a function of hops.

It is easy to create paths of arbitrary length by blocking peers
and/or disabling mesh_auto_open_plinks.
With iperf, measure the throughput as a number of hops.
You should be getting the familiar 1/n curve for single channel mesh.

That should keep you busy over the weekend... ;)

Cheers,

Javier


-- 
Javier Cardona
cozybit Inc.