Mesh test at scale

Brian DeLacey bdelacey at gmail.com
Thu Mar 5 18:37:26 EST 2009


Thanks, Javier ... I'll have to figure out how to use that ...

Is it legit to set up the routing parameters and then use ping results as a
measure? That gives us good information on packets transmitted, received,
and packet loss as well as rtt min/avg/max/mdev.

Brian


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

> Brian,
>
> 2009/3/5 Brian DeLacey <bdelacey at gmail.com>:
> > Is there any command line program / info that will tell average number of
> > hops at reception without instrumenting code?
>
> Not directly, but you might be able to infer it from the stats exposed
> via debugfs:
>
> debugfs_netdev.c:
>        MESHSTATS_ADD(fwded_frames);   <<<<<
>        MESHSTATS_ADD(dropped_frames_ttl);
>        MESHSTATS_ADD(dropped_frames_no_route);
>        MESHSTATS_ADD(estab_plinks);
>
> Cheers,
>
> Javier
>
>
> > 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
> >
> >
> > _______________________________________________
> > Devel mailing list
> > Devel at lists.open80211s.org
> > http://open80211s.com/mailman/listinfo/devel
> >
> >
>
>
>
> --
> 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/c2a9900d/attachment.html 


More information about the Devel mailing list