Mesh test at scale

[Brian DeLacey]

Hi Javier,

Thanks for this test guide. My intent is to automate as much as possible
while trying to avoid writing any new stack code instrumentation. I am
thinking of using Pexpect (http://pypi.python.org/pypi/pexpect) to build a
Python test control panel. This should be reasonably easy to read,
understand, and extend.

Is there any command line program / info that will tell average number of
hops at reception without instrumenting code? Or perhaps there is some
precompiled debug versions already that would give us the data we need?

Perhaps a souped up version of "mpath dump" or "station dump" might do this
in the future? Or maybe we can follow packets from the outside looking in,
with a checkpoint-server at each node that would trace the traffic?

Brian


On Thu, Mar 5, 2009 at 12:45 PM, Javier Cardona <javier at cozybit.com> wrote:

> 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.
> _______________________________________________
> Devel mailing list
> Devel at lists.open80211s.org
> http://open80211s.com/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://open80211s.com/pipermail/devel/attachments/20090305/adce5217/attachment.html