[olpc-nz] diagnosing ad-hoc network activity sharing problems
quozl at laptop.org
Tue Jan 25 20:30:43 EST 2011
On Sat, Jan 22, 2011 at 06:22:44PM +1300, Tabitha Roder wrote:
> Collaboration seems better than au852-4 we tested last week, but it
> still doesn't work reliably.
Collaboration is not intended to be reliable when using ad-hoc
networking. TCP is not used, and so recovery from data loss takes a
retransmission, and this retransmission occurs very slowly. (Decreasing
this would lead to further contention, since there is no congestion
Collaboration via a server is intended to be reliable. See if you can
> We had ivy able to see monkey, but monkey unable to see ivy. Tux could
> see monkey, but couldn't see couldn't see monkey's shared chat
> activity. XO 1.0 and XO 1.5 on adhoc networking.
Your observations do not match mine. I've found XO presence on
neighbourhood view and the sharing of activities very reproducible over
ad-hoc. Therefore either the laptops or the environment differ.
> How do we diagnose this?
Diagnose by dividing the problem.
If you can demonstrate that the cause of the failure is due to packet
loss across the ad-hoc network, then you can avoid worrying about the
activities, Sugar, and the operating system build, and instead worry
about hardware, operating position, temperature, humidity, and radio
To test for packet loss alone, set up an ad-hoc network, determine the
IP addresses, and ping from laptop to laptop for a reasonable sample
ping -c 1000 169.254.8.210
In my environment I see no packets lost in this test. Run this test
once with no activity sharing. Run it between each pair of laptops.
You might then run it in parallel with other testing, provided you have
less than a full classroom of XOs, otherwise the test may interfere.
Take note of the result. Sugar activity and presence sharing over
ad-hoc will be harmed by any loss.
To test for packet loss as cause of activity sharing problems, configure
each laptop to record all network traffic. Then attempt a shared
activity, and note when a problem occurs. Then analyse the traffic
later, comparing the number of packets sent by node against the number
received by other nodes.
To record all network traffic, as root:
tcpdump -i eth0 -w file -s 0
The output can be processed by wireshark.
More information about the olpc-nz