Monday's Testing

[david at lang.hm]

thanks for the list of conditions

On Fri, 28 Mar 2008, Greg Smith (gregmsmi) wrote:

> Hi Wad, et al,
>
> I think some use cases and requirements definition would be helpful
> here. I don't think the field understands clearly what Mesh and
> collaboration support and that can lead to misalignment of design and
> usage.
>
> Here is an example of possible use case definition, hopefully relevant
> variables for SW design:
>
> 1 - School has server and Active Antenna (AA) (1,2, or 3) (example?
> maybe Uruguay)
>
> 2 - School has wireless AP and server (Nepal)
>
> 3 - School has wireless AP and no server (Cambodia)
>
> 4 - School has no wireless AP or server (aka no internet ala some
> schools in Peru)
>
> 5 - School has n (50, 100, 150, 200) Xos on simultaneously

should the mesh even be used in a high-density school setting? (even with 
an AA), or should the XOs basicly operate in infrastructure mode where 
they route everything through the AA or AP?

if the density is high enough everything is within 1 RF hop (or 2 RF hops, 
one to the AA/AP, and another back out over a different channel)

in these conditions should the XO even try to route through another XO?

David Lang

> 6 - XO closest to AP or AA providing intermediate hop to internet for
> Xos (1, 2, 3 max? hops away)
>
> 7 - n (50, 100, 150) Xos in class and m laptops providing intermediate
> hops to internet (I can also see a whole bunch of "tree" cases and
> combinations of roots and branches getting to the internet).
>
> Looking at the collaboration "layer" (may need Mesh, ad hoc and eJabber
> versions, may also need AP, AA and no net versions, not sure)
>
> 8 - n (1,2,3 max?) classes of students of m each (up to 50?) using XO
> simultaneously. Classes are x feet apart and Xos 2 feet apart within a
> class (does physical granularity matter at this level?). No need to Mesh
> (L2) or collaborate (L5?) between classes. (different subnets?)
>
> 9 - One class in the school yard with kids running around and two others
> in class. Means XOs turned on and off and moving closer and farther away
> rapidly (my twins out ran me at 3 years old I hope 50 x 3rd graders
> can't out run the dynamic mesh :-)
>
> 10 - Two students sharing a book or activity with each other *25 (max?)
> for all pairs of students in class.
>
> 11 - Teacher sharing an activity with all 50 students *n classes within
> a school (1,2,3,4, n) (also list activities if relevant - e.g. web
> browsing vs. others?)
>
> 12 - Two students watching a video (don't know if its supported, but
> find high BW and low BW examples) *25 for class
>
> 13 - Teacher sharing video with all students (same note as above)
>
> 14 - 1/2 class sharing high BW, half sharing low BW activities
>
> 15 - Students form groups of 3 - 5 who all share (low and high BW)
> activities *n groups per class. Groups forming and dividing rapidly at
> start then settling down.
>
> 16 - Everyone turns on XO at the same time *n (50, 100, 150 etc). Class
> starts with 2 - 3 Xos firing up every minute for 10 minutes. Another
> class in range has all 50 Xos on already.
>
> Etc.
>
> I hope I didn't munge my mesh and collaboration layers too much.
>
> My point is that at the end of this testing you need to have some clear,
> user understandable supported setups. Nail one or two, bound them well,
> and say they are supported.
>
> Also, define what "supported" means. For example:
>
> A - Works with same speed as XO solo or works %x slower
>
> B - Access internet takes up to 50 seconds for first packet out and
> latency of .1 second after that per XO hop away from AP
>
> C- Mouse move on one XO has y latency to appear on second XO and y + z
> latency to appear on n (>1) Xos.
>
> Etc.
>
> Nail a few supported uses and we can drive everyone to start with those.
> Even better, give general guidelines and list unsupported uses.
>
> That's a quick brainstorm on my part but I haven't actually used XO to
> collaborate. Ask the schools and educators how they use it or want to
> use it. It takes a long time to develop a meaningful dialog but find
> some representative users who get back to you quickly for starters.
>
> If all of these use cases are supported, that's great as long as they
> all work. You should still say what is supported at the user level as
> people will have other ideas that we never even thought of...
>
> Way too much work to do before Monday but think of one or two cases you
> know work after this testing. Then ask educators if they fit. Then we
> tell all customers to start with that!
>
> HTHs.
>
> Thanks,
>
> Greg S
>
> ***********
> Wad -
>
> Some people will say that reactive protocols are bursty and route
> acquisition time is long. I don't disagree.
> But I believe we have room for improvement without any radical (and
> costly) change. The key is to adapt.
> We are very focused now on dense clouds (for good reasons), but our
> parameters are sub-optimal for this scenario.
>
> In a dense scenario, we should:
> 1 - Eliminate probe responses
> 2 - Increase contention window
> 3 - Increase route expiration time
> 4 - Increase multicast transmission rate
>
> My suggestion for the Cambrige testbed is:
> 1 - Validade probe response driver patch submitted by Marvell and
> implement it
> 2 - Increase contention window from 7,31 ro 31, 1023
> 3 - Increase route expiration time from 10 to 20 seconds
> 4 - Increase mcast rate from 2 to 11 Mbps.
>
> All of the above are trade offs and should be considered in dense mesh
> scenarios only. Based on what I see in my own testbed, they will reduce
> the duration of bursts and also make you more resilient to them.
>
> ***************
> It is safe to change these values on the fly.
> Marvell was discussing doing it automatically.
> A simple heuristic to check if there is congestion is to check the
> retransmission counters. So this is a relatively simple to implement
> adaptive behavior.
>
> M
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>