[OLPC-AU] Testing Summary: 10 March 2012 - Auckland, New Zealand

Jerry Vonau jvonau at shaw.ca
Sun Mar 11 09:52:41 EDT 2012


On Sun, 2012-03-11 at 21:51 +1300, Tabitha Roder wrote:
> au196 on XO-1.5 summary (details below):
> * Music Painter problems reported previously are (now?) intermittent

Noted, thanks.

> * Font in Terminal is still too big

There is a "zoom" function listed when you hover over the "eye"(third
button from the left) that changes the font size on the fly.

> * Chat is very chatty on the network

Is with or without a school-server being utilized?

> * ARP requests do not wake a laptop from suspend-resume
> * Regular “mdns” broadcasts keep waking laptops up
> 
That is intended behaviour by upstream, those are both by design.  
Think mdns traffic your seeing is outbound from the XO which controls
the presence service thus what is shown in the neighbourhood view.


> os29 on XO-1.75 summary (details below)
> * ARP requests do not wake a laptop from suspend-resume
> * Google Docs on Browse seems much more stable if suspend-resume is
> turned off
> 
> Rachel did some work on the testing pages on http://wiki.laptop.org
> and we also tested Analyze_Journal and Sin diente (details below).
> 
> 
> Music painter v9 on XO-1.5s running build 196 for Australia. Found it
> intermittently does not work. Note that Ivy and Rosella are production
> XO-1.5s and Tank is a prototype.
> We tested on Rosella (firmware 22), Ivy (23) & Tank (22). On 3
> iterations of shutdown, startup, start music paint as new, Music
> painter:
> * worked on Rosella twice 
> * worked on Ivy twice 
> * never worked on Tank
> Our n of 3 is not big enough to show that the failure rate of Tank is
> statistically different from the other 2.
> 

Think the issue maybe that musicpainter is not fully initialized when
the XO goes into suspend and may be the cause of that.

> 
> Record on Rosella - can take pictures and long movies at high res, did
> not test audio nor audio on movies
> 
> 
> Speak on Tank - don’t see any issue with the tool bar. 
> Spirolaterals on Tank: seems to be working ok.
> Terminal on Tank: Font still too big?
> Physics on Tank: Still have the issue of when I draw lines that I see
> the cursor trail but does not construct a line - this is when there
> are no other objects there, so probably not a memory or buffer
> problem. Circle, square, motor all seem okay. 
> Arithmetic on Tank: it is annoying that I have to wait for several
> seconds after I enter an answer and it tells me it is correct before
> it goes to the next question. Suggest the time restarts once the
> answer is labelled as correct. 
> Tuxmath on Tank: tried to play but then realised my migraine is not
> letting me add :). 
> 
> 
> Wake-On-LAN testing on XO-1.5 with au196.
> Three laptops on Adhoc Network 11, 2 with power saving turned on and 1
> without, for the most part no other laptops on this network.
> 
> We find that, when sleeping, the laptop does not respond to ARP
> requests, we allowed a laptop to go to sleep and we pinged it from
> another laptop, the first 15 pings were not sent due to no ARP
> information. It seems that a multicast packet woke up the target
> laptop which then received the ARP request. The following trace was
> made with tcpdump -p on the laptop that went to sleep:
> 
> 22:06:56.270776 IP 169.254.6.176.mdns > 224.0.0.251.mdns: 0*- [0q]
> 3/0/0 (Cache flush) A 169.254.6.176, (Cache flush) SRV
> xo-a7-4c-2f.local.:5298 0 0, (Cache flush) AAAA
> fe80::217:c4ff:fea7:4c2f (129)
> 22:06:56.637739 IP 169.254.5.199.mdns > 224.0.0.251.mdns: 0 [1a] TXT
> (QM)? 39adda6e at xo-53-5b-82._presence._tcp.local. (923)
> [sleep]
> 22:07:31.022779 IP 169.254.4.6.mdns > 224.0.0.251.mdns: 0 [2q] SRV
> (QM)? 39adda6e at xo-53-5b-82._presence._tcp.local. A (QM)?
> xo-53-5b-82.local. (77)
> 22:07:31.522639 ARP, Request who-has 169.254.5.199 tell 169.254.4.6,
> length 28
> 22:07:31.522730 ARP, Reply 169.254.5.199 is-at 00:17:c4:a7:4a:02 (oui
> Unknown), length 28
> 22:07:31.527420 IP 169.254.4.6 > 169.254.5.199: ICMP echo request, id
> 1387, seq 15, length 64
> 22:07:31.527567 IP 169.254.5.199 > 169.254.4.6: ICMP echo reply, id
> 1387, seq 15, length 64
> 
> This behaviour seems to be the same on the XO-1.75 with os29.
> 

Wake_on_ARP is disabled, that is intended behaviour by upstream, both
OS'es have the latest version of powerd. 

The wake_on_lan feature is used more for preventing the XO from staying
asleep than waking the XO's from full suspend. If you were to start
pinging a target XO at 7 second intervals before a suspend cycle, you
will see the response times go up but won't fail. 

> If you join the network after chat is shared, chat does not show up in
> the neighbourhood.
> 

The newly shared activity does not propagate to the neighbourhood view
of newly connected XO's as the sharing XO has already sent the presence
announcement for the newly shared activity and I don't think the
activity rebroadcast the presence announcement. I'll check upstream if
that is intended behaviour, but I think there should be a rebroadcast
every so often to force a refresh of the neighbourhood view.

> Chat sends a lot of network traffic, even when nothing is happening,
> there is a multicast UDP packet sent every 2 or 3 seconds. With two
> laptops in the chat these packets are 29 bytes long and seems to be
> some kind of clique message:
> 22:43:01.403803 IP 169.254.6.176.14986 > 239.255.71.127.14986: UDP,
> length 29
>        0x0000:  4500 0039 0000 4000 0111 9187 a9fe 06b0
>  E..9.. at .........
>        0x0010:  efff 477f 3a8a 3a8a 0025 ec0e 436c 6971
>  ..G.:.:..%..Cliq
>        0x0020:  7565 0103 fee3 cf85 02a6 c6dd f808 5e16
>  ue............^.
>        0x0030:  eafe e3cf 856a bbc6 95                   .....j...
> 
> Joining a 3rd laptop to the chat causes all three laptops to send to
> the multicast address, and the packets are now 37 bytes long. This
> explains why suspend and resume is suppressed when Chat is running.
> This level of traffic seems excessive when nothing at all is happening
> in the application.
> 

Think that is by design, if you let the laptop fully suspend without
that traffic, you will have to wait till the network is becomes
available again and you'll have a "why is chat unresponsive when coming
out of suspend" issue.

> We observed regular multicast “mdns” which caused the laptops to wake
> up. We didn’t make a note of how often this happens, but it might have
> been as often as every 45 seconds and was certainly more often than
> every 90 seconds.
> 

Maybe that is the presence service re-sync for neighbourhood view via
mdns, not sure.

Thank You for the detailed tcpdump information. I'll have powerd setup
for persistent trace logging on the next build and would like to see the
trace results from the field. 

More details to come,

Jerry

   





More information about the OLPC-AU mailing list