Re: Mesh testing

[Robert Withrow]

Polychronis Ypodimatopoulos wrote:
> I 've been doing experiments on a 50-node testbed (703, Q2D14, 22.p9, 
> simple mesh) and getting all 50 of them to communicate consistently has 
> been hard, even in the absence no sharing or heavy workloads involved.
>
>   
How did you do the test?  Did you start them up one-by-one, in groups, 
etc.  How did you configure them to do just simple mesh with nothing 
else on top? 

I don't have the cycles Bill has, but I'm interested in what 
NetworkManager is doing too, so I'll help out where I can.

-- 
Robert Withrow, R.W. Withrow Associates, Swampscott, MA, USA
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Mesh testing

[Polychronis Ypodimatopoulos]

Robert Withrow wrote:
> Polychronis Ypodimatopoulos wrote:
>> I 've been doing experiments on a 50-node testbed (703, Q2D14, 22.p9, 
>> simple mesh) and getting all 50 of them to communicate consistently 
>> has been hard, even in the absence no sharing or heavy workloads 
>> involved.
>>
>>   
> How did you do the test?  Did you start them up one-by-one, in groups, 
> etc.  
Unfortunately, I had to start them up and update one-by-one, a very 
tiring process!
> How did you configure them to do just simple mesh with nothing else on 
> top?
There is no school server around, so the go to simple mesh by default. 
For my tests (on Cerebro), I didn't really care about this anyway.
> I don't have the cycles Bill has, but I'm interested in what 
> NetworkManager is doing too, so I'll help out where I can.
_Any_ help is greatly appreciated!

Pol


-- 
Polychronis Ypodimatopoulos
Graduate student
Viral Communications
MIT Media Lab
Tel: +1 (617) 459-6058
http://www.mit.edu/~ypod/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Mesh testing

[Michael Stone]

On Mon, May 05, 2008 at 12:39:31PM -0400, Bill Mccormick wrote:
> Yes I'm in Ottawa.   
>  
> I'm in the middle of getting a fedora 6 system setup with the source
> code etc. so I can build patches.

Please speak up if you need help finding or manipulating source code.
Also, we're happy to provide shell accounts on Fedora machines as
needed for development.

Michael
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

RE: Mesh testing

[Bill Mccormick]

Yes I'm in Ottawa.   
 
I'm in the middle of getting a fedora 6 system setup with the source
code etc. so I can build patches.
 
I want to take a good look at the n/w manager and see what it's doing. 
 
Bill
 
 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kim
Quirk
Sent: Monday, May 05, 2008 12:07 PM
To: Polychronis Ypodimatopoulos
Cc: Mccormick, Bill (CAR:CTO2); OLPC Development
Subject: Re: Mesh testing


Thanks Bill! Are you in Ottawa where we are sending the laptops for the
Nortel test bed?

Kim


On Mon, May 5, 2008 at 12:05 PM, Polychronis Ypodimatopoulos
<[EMAIL PROTECTED]> wrote:


Bill Mccormick wrote:


If nobody else is doing this, I'll volunteer.   It'll be
a couple of
days though, I'm just starting.

 


Awesome! If you do take up this unpleasant, though critical task
here are my suggestions:

Like I said before, when a user reports that "the network does
not work", this may be due to a whole lot of reasons. Being able to
consistently identify which part of the "network stack" (firmware,
driver, NetworkManager, presence stack) is malfunctioning is not
feasible anytime soon, so we better make sure that each individual layer
is this network stack has been thoroughly tested. I would suggest doing
so in two dimensions: scalability and stability.

Scalability: Making it work on 5 machines is one thing, making
it work on 50 is another! Please test on as many machines as possible.

Stability: Similarly, we should aim for at some 5 hours of
continuous and stable operation.

We currently do _not_ meet these requirements and from an
activity point of view, the network look like an  omelet rather than
distinct yoke and white!!! 



Pol

-- 
Polychronis Ypodimatopoulos
Graduate student
Viral Communications
MIT Media Lab
Tel: +1 (617) 459-6058
http://www.mit.edu/~ypod/ <http://www.mit.edu/%7Eypod/> 




___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Mesh testing

[Ricardo Carrano]

Bill,
That's great!
Would you take a look at  http://dev.laptop.org/ticket/6237 and check if
this is something that can be done within your time frame?

Cheers!
Ricardo Carrano

On Mon, May 5, 2008 at 12:40 PM, Bill Mccormick <[EMAIL PROTECTED]> wrote:

> If nobody else is doing this, I'll volunteer.   It'll be a couple of
> days though, I'm just starting.
>
> Bill McCormick
> Open innovation lab
> Nortel
> ESN 393-6298
> External (613) 763-6298
>
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Polychronis
> Ypodimatopoulos
> Sent: Monday, May 05, 2008 11:34 AM
> To: Kim Quirk
> Cc: OLPC Development
> Subject: Mesh testing
>
> I 've been doing experiments on a 50-node testbed (703, Q2D14, 22.p9,
> simple mesh) and getting all 50 of them to communicate consistently has
> been hard, even in the absence no sharing or heavy workloads involved.
>
> Out of the 50 nodes (over a period of time of 6 hours), 8 nodes
> "decided" to take msh0 down, half of which did not come up again
> (NetworkManager?).
>
> About 18 out of 50 nodes (not including the previous 8) for some reason
> stopped being reachable from the rest of the network, although their
> network interface did not seem to have been reset. Restarting the
> NetworkManager seems to fix the problem.
>
> Is anyone still maintaining the NetworkManager? It seems to me that the
> NetworkManager chooses to restart msh0 sometimes. Is this true? Does it
> go so far as to reload the firmware?
>
> Pol
>
>
> --
> Polychronis Ypodimatopoulos
> Graduate student
> Viral Communications
> MIT Media Lab
> Tel: +1 (617) 459-6058
> http://www.mit.edu/~ypod/ <http://www.mit.edu/%7Eypod/>
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Mesh testing

[Ricardo Carrano]

Pol,

I suggest you switch to 22.p10 which fixes a bug in 22.p9.
But you should not use any firmware later than 22.p6 with stock kernel
(because of the multicast filter, #6818). It surprises me that you are able
to collaborate at all.

--
Ricardo

On Mon, May 5, 2008 at 12:34 PM, Polychronis Ypodimatopoulos <[EMAIL PROTECTED]>
wrote:

> I 've been doing experiments on a 50-node testbed (703, Q2D14, 22.p9,
> simple mesh) and getting all 50 of them to communicate consistently has
> been hard, even in the absence no sharing or heavy workloads involved.
>
> Out of the 50 nodes (over a period of time of 6 hours), 8 nodes
> "decided" to take msh0 down, half of which did not come up again
> (NetworkManager?).
>
> About 18 out of 50 nodes (not including the previous 8) for some reason
> stopped being reachable from the rest of the network, although their
> network interface did not seem to have been reset. Restarting the
> NetworkManager seems to fix the problem.
>
> Is anyone still maintaining the NetworkManager? It seems to me that the
> NetworkManager chooses to restart msh0 sometimes. Is this true? Does it
> go so far as to reload the firmware?
>
> Pol
>
>
> --
> Polychronis Ypodimatopoulos
> Graduate student
> Viral Communications
> MIT Media Lab
> Tel: +1 (617) 459-6058
> http://www.mit.edu/~ypod/ 
>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Mesh testing

[Kim Quirk]

Thanks Bill! Are you in Ottawa where we are sending the laptops for the
Nortel test bed?

Kim

On Mon, May 5, 2008 at 12:05 PM, Polychronis Ypodimatopoulos <[EMAIL PROTECTED]>
wrote:

> Bill Mccormick wrote:
>
> > If nobody else is doing this, I'll volunteer.   It'll be a couple of
> > days though, I'm just starting.
> >
> >
> >
> Awesome! If you do take up this unpleasant, though critical task here are
> my suggestions:
>
> Like I said before, when a user reports that "the network does not work",
> this may be due to a whole lot of reasons. Being able to consistently
> identify which part of the "network stack" (firmware, driver,
> NetworkManager, presence stack) is malfunctioning is not feasible anytime
> soon, so we better make sure that each individual layer is this network
> stack has been thoroughly tested. I would suggest doing so in two
> dimensions: scalability and stability.
>
> Scalability: Making it work on 5 machines is one thing, making it work on
> 50 is another! Please test on as many machines as possible.
>
> Stability: Similarly, we should aim for at some 5 hours of continuous and
> stable operation.
>
> We currently do _not_ meet these requirements and from an activity point
> of view, the network look like an  omelet rather than distinct yoke and
> white!!!
>
>
>
> Pol
>
> --
> Polychronis Ypodimatopoulos
> Graduate student
> Viral Communications
> MIT Media Lab
> Tel: +1 (617) 459-6058
> http://www.mit.edu/~ypod/ 
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Mesh testing

[Polychronis Ypodimatopoulos]

Bill Mccormick wrote:
> If nobody else is doing this, I'll volunteer.   It'll be a couple of
> days though, I'm just starting.
>
>   
Awesome! If you do take up this unpleasant, though critical task here 
are my suggestions:

Like I said before, when a user reports that "the network does not 
work", this may be due to a whole lot of reasons. Being able to 
consistently identify which part of the "network stack" (firmware, 
driver, NetworkManager, presence stack) is malfunctioning is not 
feasible anytime soon, so we better make sure that each individual layer 
is this network stack has been thoroughly tested. I would suggest doing 
so in two dimensions: scalability and stability.

Scalability: Making it work on 5 machines is one thing, making it work 
on 50 is another! Please test on as many machines as possible.

Stability: Similarly, we should aim for at some 5 hours of continuous 
and stable operation.

We currently do _not_ meet these requirements and from an activity point 
of view, the network look like an  omelet rather than distinct yoke 
and white!!!


Pol

-- 
Polychronis Ypodimatopoulos
Graduate student
Viral Communications
MIT Media Lab
Tel: +1 (617) 459-6058
http://www.mit.edu/~ypod/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

RE: Mesh testing

[Bill Mccormick]

If nobody else is doing this, I'll volunteer.   It'll be a couple of
days though, I'm just starting.

Bill McCormick
Open innovation lab
Nortel
ESN 393-6298
External (613) 763-6298 
 
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Polychronis
Ypodimatopoulos
Sent: Monday, May 05, 2008 11:34 AM
To: Kim Quirk
Cc: OLPC Development
Subject: Mesh testing

I 've been doing experiments on a 50-node testbed (703, Q2D14, 22.p9,
simple mesh) and getting all 50 of them to communicate consistently has
been hard, even in the absence no sharing or heavy workloads involved.

Out of the 50 nodes (over a period of time of 6 hours), 8 nodes
"decided" to take msh0 down, half of which did not come up again
(NetworkManager?).

About 18 out of 50 nodes (not including the previous 8) for some reason
stopped being reachable from the rest of the network, although their
network interface did not seem to have been reset. Restarting the
NetworkManager seems to fix the problem.

Is anyone still maintaining the NetworkManager? It seems to me that the
NetworkManager chooses to restart msh0 sometimes. Is this true? Does it
go so far as to reload the firmware?

Pol


--
Polychronis Ypodimatopoulos
Graduate student
Viral Communications
MIT Media Lab
Tel: +1 (617) 459-6058
http://www.mit.edu/~ypod/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Mesh testing

[Polychronis Ypodimatopoulos]

I 've been doing experiments on a 50-node testbed (703, Q2D14, 22.p9, 
simple mesh) and getting all 50 of them to communicate consistently has 
been hard, even in the absence no sharing or heavy workloads involved.

Out of the 50 nodes (over a period of time of 6 hours), 8 nodes 
"decided" to take msh0 down, half of which did not come up again 
(NetworkManager?).

About 18 out of 50 nodes (not including the previous 8) for some reason 
stopped being reachable from the rest of the network, although their 
network interface did not seem to have been reset. Restarting the 
NetworkManager seems to fix the problem.

Is anyone still maintaining the NetworkManager? It seems to me that the 
NetworkManager chooses to restart msh0 sometimes. Is this true? Does it 
go so far as to reload the firmware?

Pol


-- 
Polychronis Ypodimatopoulos
Graduate student
Viral Communications
MIT Media Lab
Tel: +1 (617) 459-6058
http://www.mit.edu/~ypod/

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Today's mesh testing.

[Ricardo Carrano]

On Mon, Mar 3, 2008 at 9:36 PM, C. Scott Ananian <[EMAIL PROTECTED]> wrote:

> On Sun, Mar 2, 2008 at 7:05 PM, Chris Ball <[EMAIL PROTECTED]> wrote:
> >  broadcast, and they were all able to see and join a shared chat session
> >  with each other.  The workload on the spectrum analyzer increased from
> >  18% (no-one connected) to 26% (all connected).  The chat session is
> >  consistent -- no-one is dropping out and new messages are seen by each
> >  laptop, with a few seconds of lag.
>
> I would interpret this as, "packets are being dropped like crazy, but
> retransmits assure that the chat message gets through by the time a
> few seconds elapse".  Is there any reason why chat would not be
> instantaneous otherwise?
>

This is easy to verify. Just add the following to your filter:
wlan.fc.retry == 1
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Today's mesh testing.

[Morgan Collett]

C. Scott Ananian wrote:
> How did you get sharing to use unicast?  Was this a special patch, or
> is this actually the default?  (My understanding is that sharing is
> multicast.)

telepathy-gabble via a jabber server is always unicast.

Morgan
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Today's mesh testing.

[C. Scott Ananian]

On Sun, Mar 2, 2008 at 7:05 PM, Chris Ball <[EMAIL PROTECTED]> wrote:
>  broadcast, and they were all able to see and join a shared chat session
>  with each other.  The workload on the spectrum analyzer increased from
>  18% (no-one connected) to 26% (all connected).  The chat session is
>  consistent -- no-one is dropping out and new messages are seen by each
>  laptop, with a few seconds of lag.

I would interpret this as, "packets are being dropped like crazy, but
retransmits assure that the chat message gets through by the time a
few seconds elapse".  Is there any reason why chat would not be
instantaneous otherwise?

>  With the mass chat session still running, we shared a 500KiB PDF.  First
>  we joined the shared Read session with one laptop, and the download took
>  16 seconds to complete.  We then joined two more laptops at once, the
>  first download took 26 seconds and the second finished at 30 seconds.
>  Five more at once: all finished around 1m00s.  Ten more at once:  the
>  first finished at 2m18s, the last finished at 2m40s.  There were no
>  failures downloading the PDF.  The sharing was unicast TCP, with mesh
>  TTL set to 1, which explains the slightly worse than linear increase in
>  download time for more laptops downloading at once.

How did you get sharing to use unicast?  Was this a special patch, or
is this actually the default?  (My understanding is that sharing is
multicast.)

Just for reference, a 500kB file transmits over the "media lab 802.11"
network here in 1cc in just under 4 tenths of a second.  I tested and
it easily scaled up to 10 simultaneous downloads in 4-5 seconds.  So
somehow we're running 40-65 times slower than this on the mesh,
depending on the number of clients.

>  This is much more anecdotal than the full test plan, but we thought the
>  testers currently in Peru would want to know what they can expect from
>  the school server setup ASAP.  We don't have more laptops upgraded and
>  ready to join the network yet, but we don't have any reason to believe
>  we've saturated the network -- with the PDFs downloaded and Chat still
>  running, the duty cycle on the spectrum analyzer is now at 28%.  (In
>  general, wireless networks seem to start degrading around 40%.)

Based on my reading of the numbers above, it does seem like you're
pushing the network pretty hard.  But, as wad pointed out, if we can
do 32 clients on one channel of a school server, we can support the
100-laptop school scenario with three active antennas.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Today's mesh testing.

[Jim Gettys]

Wonderful stuff!
  - Jim

On Sun, 2008-03-02 at 19:05 -0500, Chris Ball wrote:
> Hi,
> 
> Daf and I got the school server jabberd/shared roster working today.
> We connected/registered 32 laptops to it with mesh TTL set to 1 for
> broadcast, and they were all able to see and join a shared chat session
> with each other.  The workload on the spectrum analyzer increased from
> 18% (no-one connected) to 26% (all connected).  The chat session is
> consistent -- no-one is dropping out and new messages are seen by each
> laptop, with a few seconds of lag.
> 
> With the mass chat session still running, we shared a 500KiB PDF.  First
> we joined the shared Read session with one laptop, and the download took
> 16 seconds to complete.  We then joined two more laptops at once, the
> first download took 26 seconds and the second finished at 30 seconds.
> Five more at once: all finished around 1m00s.  Ten more at once:  the
> first finished at 2m18s, the last finished at 2m40s.  There were no
> failures downloading the PDF.  The sharing was unicast TCP, with mesh
> TTL set to 1, which explains the slightly worse than linear increase in
> download time for more laptops downloading at once.
> 
> This is much more anecdotal than the full test plan, but we thought the
> testers currently in Peru would want to know what they can expect from
> the school server setup ASAP.  We don't have more laptops upgraded and
> ready to join the network yet, but we don't have any reason to believe
> we've saturated the network -- with the PDFs downloaded and Chat still
> running, the duty cycle on the spectrum analyzer is now at 28%.  (In
> general, wireless networks seem to start degrading around 40%.)
> 
> - Chris and Daf.
-- 
Jim Gettys
One Laptop Per Child


___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Today's mesh testing.

[Kim Quirk]

Great! Thanks for the update, Chris.

Kim

On Sun, Mar 2, 2008 at 7:05 PM, Chris Ball <[EMAIL PROTECTED]> wrote:

> Hi,
>
> Daf and I got the school server jabberd/shared roster working today.
> We connected/registered 32 laptops to it with mesh TTL set to 1 for
> broadcast, and they were all able to see and join a shared chat session
> with each other.  The workload on the spectrum analyzer increased from
> 18% (no-one connected) to 26% (all connected).  The chat session is
> consistent -- no-one is dropping out and new messages are seen by each
> laptop, with a few seconds of lag.
>
> With the mass chat session still running, we shared a 500KiB PDF.  First
> we joined the shared Read session with one laptop, and the download took
> 16 seconds to complete.  We then joined two more laptops at once, the
> first download took 26 seconds and the second finished at 30 seconds.
> Five more at once: all finished around 1m00s.  Ten more at once:  the
> first finished at 2m18s, the last finished at 2m40s.  There were no
> failures downloading the PDF.  The sharing was unicast TCP, with mesh
> TTL set to 1, which explains the slightly worse than linear increase in
> download time for more laptops downloading at once.
>
> This is much more anecdotal than the full test plan, but we thought the
> testers currently in Peru would want to know what they can expect from
> the school server setup ASAP.  We don't have more laptops upgraded and
> ready to join the network yet, but we don't have any reason to believe
> we've saturated the network -- with the PDFs downloaded and Chat still
> running, the duty cycle on the spectrum analyzer is now at 28%.  (In
> general, wireless networks seem to start degrading around 40%.)
>
> - Chris and Daf.
> --
> Chris Ball   <[EMAIL PROTECTED]>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Today's mesh testing.

[Walter Bender]

Really is good news. Something we can work from.

-walter

On Sun, Mar 2, 2008 at 10:13 PM, John Watlington <[EMAIL PROTECTED]> wrote:
>
>  Thanks for the info !   This is good news, as it means that schools
>  up to a hundred students should work right now, given a school server
>  and three active antennas...
>
>  wad
>
>
>
>  On Mar 2, 2008, at 7:05 PM, Chris Ball wrote:
>
>  > Hi,
>  >
>  > Daf and I got the school server jabberd/shared roster working today.
>  > We connected/registered 32 laptops to it with mesh TTL set to 1 for
>  > broadcast, and they were all able to see and join a shared chat
>  > session
>  > with each other.  The workload on the spectrum analyzer increased from
>  > 18% (no-one connected) to 26% (all connected).  The chat session is
>  > consistent -- no-one is dropping out and new messages are seen by each
>  > laptop, with a few seconds of lag.
>  >
>  > With the mass chat session still running, we shared a 500KiB PDF.
>  > First
>  > we joined the shared Read session with one laptop, and the download
>  > took
>  > 16 seconds to complete.  We then joined two more laptops at once, the
>  > first download took 26 seconds and the second finished at 30 seconds.
>  > Five more at once: all finished around 1m00s.  Ten more at once:  the
>  > first finished at 2m18s, the last finished at 2m40s.  There were no
>  > failures downloading the PDF.  The sharing was unicast TCP, with mesh
>  > TTL set to 1, which explains the slightly worse than linear
>  > increase in
>  > download time for more laptops downloading at once.
>  >
>  > This is much more anecdotal than the full test plan, but we thought
>  > the
>  > testers currently in Peru would want to know what they can expect from
>  > the school server setup ASAP.  We don't have more laptops upgraded and
>  > ready to join the network yet, but we don't have any reason to believe
>  > we've saturated the network -- with the PDFs downloaded and Chat still
>  > running, the duty cycle on the spectrum analyzer is now at 28%.  (In
>  > general, wireless networks seem to start degrading around 40%.)
>  >
>  > - Chris and Daf.
>  > --
>  > Chris Ball   <[EMAIL PROTECTED]>
>  > ___
>  > Devel mailing list
>  > Devel@lists.laptop.org
>  > http://lists.laptop.org/listinfo/devel
>
>  ___
>  Devel mailing list
>  Devel@lists.laptop.org
>  http://lists.laptop.org/listinfo/devel
>



-- 
Walter Bender
One Laptop per Child
http://laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Today's mesh testing.

[John Watlington]

Thanks for the info !   This is good news, as it means that schools
up to a hundred students should work right now, given a school server
and three active antennas...

wad

On Mar 2, 2008, at 7:05 PM, Chris Ball wrote:

> Hi,
>
> Daf and I got the school server jabberd/shared roster working today.
> We connected/registered 32 laptops to it with mesh TTL set to 1 for
> broadcast, and they were all able to see and join a shared chat  
> session
> with each other.  The workload on the spectrum analyzer increased from
> 18% (no-one connected) to 26% (all connected).  The chat session is
> consistent -- no-one is dropping out and new messages are seen by each
> laptop, with a few seconds of lag.
>
> With the mass chat session still running, we shared a 500KiB PDF.   
> First
> we joined the shared Read session with one laptop, and the download  
> took
> 16 seconds to complete.  We then joined two more laptops at once, the
> first download took 26 seconds and the second finished at 30 seconds.
> Five more at once: all finished around 1m00s.  Ten more at once:  the
> first finished at 2m18s, the last finished at 2m40s.  There were no
> failures downloading the PDF.  The sharing was unicast TCP, with mesh
> TTL set to 1, which explains the slightly worse than linear  
> increase in
> download time for more laptops downloading at once.
>
> This is much more anecdotal than the full test plan, but we thought  
> the
> testers currently in Peru would want to know what they can expect from
> the school server setup ASAP.  We don't have more laptops upgraded and
> ready to join the network yet, but we don't have any reason to believe
> we've saturated the network -- with the PDFs downloaded and Chat still
> running, the duty cycle on the spectrum analyzer is now at 28%.  (In
> general, wireless networks seem to start degrading around 40%.)
>
> - Chris and Daf.
> -- 
> Chris Ball   <[EMAIL PROTECTED]>
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Today's mesh testing.

[Chris Ball]

Hi,

Daf and I got the school server jabberd/shared roster working today.
We connected/registered 32 laptops to it with mesh TTL set to 1 for
broadcast, and they were all able to see and join a shared chat session
with each other.  The workload on the spectrum analyzer increased from
18% (no-one connected) to 26% (all connected).  The chat session is
consistent -- no-one is dropping out and new messages are seen by each
laptop, with a few seconds of lag.

With the mass chat session still running, we shared a 500KiB PDF.  First
we joined the shared Read session with one laptop, and the download took
16 seconds to complete.  We then joined two more laptops at once, the
first download took 26 seconds and the second finished at 30 seconds.
Five more at once: all finished around 1m00s.  Ten more at once:  the
first finished at 2m18s, the last finished at 2m40s.  There were no
failures downloading the PDF.  The sharing was unicast TCP, with mesh
TTL set to 1, which explains the slightly worse than linear increase in
download time for more laptops downloading at once.

This is much more anecdotal than the full test plan, but we thought the
testers currently in Peru would want to know what they can expect from
the school server setup ASAP.  We don't have more laptops upgraded and
ready to join the network yet, but we don't have any reason to believe
we've saturated the network -- with the PDFs downloaded and Chat still
running, the duty cycle on the spectrum analyzer is now at 28%.  (In
general, wireless networks seem to start degrading around 40%.)

- Chris and Daf.
-- 
Chris Ball   <[EMAIL PROTECTED]>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Mesh testing on Monday.

[Morgan Collett]

Chris Ball wrote:
>5. Read -- if one laptop shares a PDF, how many laptops fail to
>   retrieve it?

Joyride 1721 has a fix in Salut for #6483, Stream Tubes issue in sharing
a PDF in Read.

Therefore, we recommend that build for testing.

Morgan

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Mesh testing on Monday.

[Chris Ball]

Hi,

Here's a plan for Monday's mesh test.  Feel free to edit it.

   http://wiki.laptop.org/go/Mesh_Testing

Plaintext copy of the current revision enclosed below:

===

This page describes the network testing that will be performed on Monday
Feb 25th at 1cc.

Setup:

* Start with ten machines, keep adding ten at a time while it is
  useful to do so.

Measurements to make during each test (in addition to workload-specific
measurements):

* Spectrum utilization -- as measured w/ spectrum analyzer and/or
  from wireshark
  o Wireshark may be able to break down bandwidth by packet type 
* Remaining bandwidth -- attempt to download a large file on one
  machine during test, record time taken or bandwidth achieved.
* Total # of laptops seen on mesh view on all numbers (should be n^2). 

Workloads -- tests to perform, along with their quantitative metrics:

   1. Idle load.
   2. Every machine coming out of suspend (or booting).
   3. Every machine trying to register with school server -- Number of
  machines that failed the first attempt, failed second attempt, etc.
   4. Ricardo's web spider at various rates of download (download 1k
  page/second, etc)
   5. Read -- if one laptop shares a PDF, how many laptops fail to
  retrieve it?
   6. Distance -- binary success/fail. Are there other metrics?
   7. Write -- automate pressing N characters a second for small N, look at
  received rate/update time, increase number of participants.
   8. olpc-update -- number of machines upgraded in 1 hour 

Variables to investigate:

* Set mesh ttl to 1 for every packet
* Change bcast/mcast rate on every node
* Jim's Avahi config 30% fixes?
* Presence: Benchmark bandwidth use of Avahi vs. Cerebro vs. no presence?
* Collaboration: Benchmark switching from multicast to unicast?
* Suspend/resume: Off vs. on, wake-on-unicast vs. wake-on-multicast
* Block multicast in route table (are there other sources of
  multicast packets other than the above?)
* Are there other mesh parameters to tweak? Path request timeout,
  for example.

- Chris.
-- 
Chris Ball   <[EMAIL PROTECTED]>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel