#7512 NORM 8.1.1 (: Transferring full-size image files is possible only between two machines at a time

[Zarro Boogs per Child]

#7512: Transferring full-size image files is possible only between two machines at
a time
-------------------------------+--------------------------------------------
   Reporter:  joe              |       Owner:  mbletsas             
       Type:  defect           |      Status:  new                  
   Priority:  normal           |   Milestone:  8.1.1 (was Update1.1)
  Component:  camera-activity  |     Version:  Update.1             
 Resolution:                   |    Keywords:                       
Next_action:  never set        |    Verified:  0                    
  Blockedby:                   |    Blocking:                       
-------------------------------+--------------------------------------------

Comment(by carrano):

 Here is my first test with transferring pictures between 4 XOs (all of
 them running stock candidate-708 build).

 1 - XO1 started the record activity and shared to the neighbourhood. The
 other 3 XOs (XO2,XO3 and XO4) joined.

 2 - From XO1, a picture was taken. Thumbnails were immediately received on
 all other 3 nodes.

 3 - The previous step was repeated three times. All successfully

 4 - XO2 requested the full size image. Success.

 5 - The previous step was repeated for XO3 and XO4. All successfully.

 6 - All three XOs requested another picture at the same time (0.1 second
 precision). Received with success in all three cases.

 Initial conclusions:

 It is not accurate that "Transferring full-size image files is possible
 only between two machines at a time". Tests involved 4 (one transmitting
 and three receiving) successfully. It may be the case that it would work
 with more.

 The environment was not particularly challenging (since the test was
 performed in off hours) but it was not a silent environment either (the
 Computer Science Department at Princeton University).

 It is worth noting that the transfer took 85%+ of the available airtime
 during 8.5 seconds. The transfer was performed via MDNS UDP datagrams at
 the rate of 2Mbps and that is (not the size in bytes) the reason for the
 congested period.

 Were the original tests performed at 1cc? Under typical 1cc conditions the
 available spectrum will be seriously constrained and this will probably
 prevent that tests there get similar results. 1cc should be considered an
 extremely challenging scenario.

 It is now important to determine what exactly is failing. Although I'll
 try to stress the scenario and reproduce the failure, we should
 concentrate in narrowing down the possible causes and better
 characterizing the crash and this is probably easier at 1cc.

 Some simple questions that may help us with the diagnosis:

 - Is the XO able to start and share other activities?

 - Is telepathy-salut still running? ("ps aux | grep telepathy-salut")

 - Is the wireless subsystem still active? ("iwpriv msh0 fwt_time")

 Note: A congested medium is no reason for an activity to crash. A crash
 implies bugs anywhere on the stack, up to the activity itself. Recent
 tests with traffic generators that clog the spectrum in much more severe
 conditions have not crashed the wireless subsystem or forced me to reboot
 the XOs. Based on that, if we are indeed having crashes associated to
 congestion (can we say that for sure?), it seems that we are dealing with
 an application/middleware problem that may or may not be triggered by
 lower layers (loss of frames->packets->messages).

-- 
Ticket URL: <http://dev.laptop.org/ticket/7512#comment:5>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system