problems using the measure activity.

[John Gilmore]

> > we did try this with -rc2 (we upgraded 4-5 machines to -rc2 over the
> > wekend.)
> 
> I just tried it again with my two machines and it worked for about 60 
> seconds (at which time the one running on battery did a suspend and the 
> activity stopped)

Why would an activity break when awaiting packets and the system suspends?
It's supposed to break out of suspend when the next packet arrives.

Oh!  Because the activity sharing/association stuff uses multicast
packets, and there's bug http://dev.laptop.org/ticket/4616, "Mesh
doesn't resume from suspend on reciept of multicast packets".

If you create some file somewhere, then Ohm won't suspend.  (Chris,
how about adding a real control for this into the olpc-control-panel?)
You could do the research to find that file, then create it, then see
how Distance works.  I can see that you'd have problems sharing the
two instances, due to the bug, but then once they are paired, they
ought to be using unicast packets (via TCP), right?  Sending a unicast
packet would wake the laptop on the other end out of suspend (this is
supposed to be working -- but takes a full second or so).  So is there
another bug, either in Distance, in the infrastructure between shared
activities, or in suspending, that is causing Distance to fail once fully
shared?

Unfortunately, fixing that multicast bug may be hard.  It took months
to convince OLPC that it ought to get fixed, despite the fact that it
breaks every incoming IPv6 connection.  The WiFi firmware supposedly
already supports resuming on reciept of interesting multicast packets;
we just aren't asking to be awakened for them.  The problem is that
the laptop's presence software is listening to (and transmitting) way
too many multicast packets all the time -- so it would pop out of
suspend all the time.

Once the presence service gets the network traffic down to a dull
roar, and the suspend/resume time gets shorter, it'll be easier to
fix.

	John