Assorted Data on the Quality of our Networking, Presence, and Read Sharing Capabilities

Michael Stone michael at laptop.org
Thu Mar 20 13:41:42 EDT 2008


Friends,

Chris Ball and I spend several hours last night measuring the behavior
of Read sharing. The data we collected are reproduced below.

Michael





A Fragment of the Critical Path for Successful Read Sharing
----------------------------------------------------------------


This chart was created based on general knowledge of the Telepathy, Sugar
Presence Service, Sugar python libraries, and the Read source code at 

http://dev.laptop.org/git?p=projects/read-activity;a=blob;f=readactivity.py;hb=HEAD


                          *
                          |
XOs join the network      |
                          |
                          |
                          *
                          |
Read is started on        |
the "sharer"              |
                          |
                   /------*------\
                  /               \
invitations      /                 \   the "sharer" is 
are sent        |                   |  marked "public"
                 \                 /
                  \               /
                   \------*------/
                          |
Joiners recognize the     |  
presence of the shared    |  
activity                  |
                          *
                          |
Join commands are issued  |    
to Sugar                  |
                          |
                          *
Read instances look for   |
Tubes, register callbacks |
for new Tubes             |
                          |
                          *
                          |
...                       |
                          |
                          |
                          *
                          |
After accepting a new     |
tube, the joining act.    |
issues an HTTP request    |
                          *
                          |
...                       |
                          |
                          |
                    ------*-------
                   /      |       \
Results           /       |        \
                 /        |         \
                /         |          \
            success   divergence   failure





Experimental Setup
----------------------------------------------------------------

A Log of our measurements follows.

All experiments were conducted with four B4s (MS1, MS2, MS3, MS4)
running update.1-699 and Read-44.xo. The build log for 699 is here:

  http://pilgrim.laptop.org/~pilgrim/xo-1/streams/update.1/build699/devel_jffs2/build.log

if you need to see what software is in the build.





Simple Mesh, Sequential Invitations
----------------------------------------------------------------

We created a simple mesh on Channel 11 and extended invitations to
join a Phyla.pdf (under Library > Biology; ~2.5 MB) session from 
             
                    MS1 -I> (MS3, MS4).

The invitations were received on both MS3 and MS4.

First, we caused MS3 to accept the invitation. MS3 successfully
displayed the shared PDF. Then we caused MS4 to accept the invitation.
MS4 displayed the shared PDF.





Simple Mesh, Simultaneous Invitations
----------------------------------------------------------------

Still on Channel 11, simple mesh; we closed all open instances of Read
and reopened Phyla.pdf on MS1. We extended invitations from

                    MS1 -I> (MS3, MS4)

The invitations were received on both MS3 and MS4.

We caused MS3 and MS4 to accept their invitations simultaneously. Both
MS3 and MS4 displayed the shared PDF after about 5-10 seconds of data
transfer.

  NB: Joining Read instances do not save the actual PDFs they receive to
  the DS. There is a comment in the source code stating this fact but
  there is no explanation of _why_ this decision was made. If you know
  why, please let us know.



Connecting to an AP
----------------------------------------------------------------

Next we connected MS1, MS2, MS3, and MS4 to the channel 6 "media
802.11" AP.

MS1, MS2, and MS4 all connected successfully on the first try and
received presence updates.

MS3's connection icon changed to indicate that it was connected to the
AP but it received no presence information. 

  'olpc-netstatus' on MS3 reported that Salut was running but the
  "Config" field was blank. [On the other XOs, the "Config" field read
  "Access point".]

After five disconnect/reconnect attempts, MS3 made a successful
connection to the AP and presence information was exchanged.





Making Friends
----------------------------------------------------------------

In order to speed up the process of issuing invitations in the future,
we added each of MS[1,2,3,4] as a friend of each of MS[1,2,3,4]. All
XOs saw their three friends as being available. 

Unfortunately, in the mesh views on MS1, MS2, and MS4, the MS4 mesh
icon representing MS1 had a palette offering a "Remove friend" option.
All the other representing icons had palettes with the "Add friend"
option, even on the Friends View.





Dynamics of maintaining connections
----------------------------------------------------------------

MS2, which had initial difficulty connecting to the AP had a network
status display on the Home screen containing both a mesh icon and an
AP icon. The AP icon remained steady; its status did not change.

The mesh icon, however, (which was not present on the other XOs)
sometimes grayed out. Hovering over the icon reported 
  
  "Buscando un portal malla en una escuela"
  However, there were no unexpected differences between the output of
  olpc-netstatus on MS1 and MS2.





Quality of the Connection
----------------------------------------------------------------

We opened Phyla.pdf on MS1 and sent invitations to MS2 and MS4.
The invitations were not received within a period of 5 minutes.

We marked the Read instance on MS1 as publicly shared (i.e. "Share
with my neighborhood"). This presence update was not communicated to
MS2 or to MS4 within 5 minutes.

We examined the forwarding table of the msh0 interface on MS1 and were
surprised to discover that it contained entries with the MAC address
of MS4 but not MS2. 

  NB: olpc-netlog could be profitably extended to capture all
  available routing informatio. 

When trying to send pings from MS1 -> MS2 msh0, we received "destination
host unreachable" errors. When trying to send pings from MS1 -> MS4
msh0, we had 100% packet loss but no errors.

All three laptops's msh0 interfaces had IP addresses on the same
subnet. The routing table on MS1 contained an entry covering this
subnet.





Try, Try Again
----------------------------------------------------------------

In desperation, we restarted sugar on MS1, MS2, and MS4. According to
the mesh status icons on the home view, all 3 XOs came up with their
connection to the AP intact.

All the palettes on all the machines had "Remove friend" options where
they formerly had "Add friend" options.

We opend Phyla.pdf on MS2 and sent invitations from 

                   MS2 -I> (MS1, MS4).

None were received.





Try, Try Again (2)
----------------------------------------------------------------

Next, we rebooted MS1, MS2, and MS4. After the boot sequence quiesced,
we connected all three to the same AP as before.

        MS1 and MS4 can see MS1, MS3, and MS4. 
        MS2 is invisible and can't see anyone.
        olpc-netstatus reports similar results on all 3 machines.

A Browse invitation was successfully sent from MS1 -> MS4.

A Read invitation was successfully sent from MS1 -> MS4. It was
accepted, but the join attempt failed. Logs were captured and have
been attached to 

   http://dev.laptop.org/ticket/6483
   http://dev.laptop.org/attachment/ticket/6483/logs.SHF725003A0.2008-03-19.23-56-27.tar.bz2




More information about the Devel mailing list