Idle-suspend a little too intrusive to user experience?

[John Gilmore]

>						   ...the biggest
> problem area in terms of suspending and not coming back is the
> network, and without "wake-on-precisely-what-i'm-waiting-for",
> that's problematic.

Most wireless and Ethernet chips can be configured to interrupt or
wake on precisely what you're waiting for.  They discard all packets
for other network addresses.  They discard 98% of multicasts that
you aren't listening for.  They even discard broadcasts if you ask
them to.  The really smart ones can ignore all broadcasts except for
ARPs that are for this machine (there's already a kernel interface for
this, "ethtool -s wol a", which we got working late in the XO-1.)

I don't know what wireless chip made it into the XO-1.5 (the XO-1.5
hardware spec wiki page just says a "QMI WLAN module" with no data
sheet, and the PDF page is even less informative), so I don't know
just how fancy its wake-on-lan configuration is.

If our new chip is not fancy, it might even be possible to cheat with
a mite of code to the resume sequence in Open Firmware.  This would
look for an incoming ARP that wasn't for us, and quickly put us back
to sleep before turning on the DRAM and video and such.  Before going
to that premature optimization, we should see how many times our
suspend-on-idle kernel wakes up and then immediately decides to go
back to sleep.  If it's uncommon, no need to bother.

	John