5:52 p.m.
http://wiki.laptop.org/go/F11_for_1.5
http://build.laptop.org/10.2.0/os112
Compressed image size: 678.89mb (+0.16mb since build 111)
Description of changes in this build:
* Switch from ohmd to powerd
* New kernel includes userspace controls for camera exposure
* New firmware Q3A35
* Pull F11 updates
Package changes since build 111:
+GConf2-2.26.2-1.fc11.1.i586
-GConf2-2.26.2-1.fc11.i586
+GConf2-gtk-2.26.2-1.fc11.1.i586
-GConf2-gtk-2.26.2-1.fc11.i586
-abiword-2.8.1-1.fc11.i586
+abiword-2.8.2-1.fc11.i586
-bootfw-q3a32-1.unsigned.i386
+bootfw-q3a35-1.unsigned.i386
-cups-libs-1.4.2-23.fc11.i586
+cups-libs-1.4.2-26.fc11.i586
-kernel-2.6.31_xo1.5-20100301.1340.1.olpc.2671e48.i586
+kernel-2.6.31_xo1.5-20100306.2110.1.olpc.655e269.i586
-kernel-firmware-2.6.31_xo1.5-20100301.1340.1.olpc.2671e48.i586
+kernel-firmware-2.6.31_xo1.5-20100306.2110.1.olpc.655e269.i586
-libabiword-2.8.1-1.fc11.i586
+libabiword-2.8.2-1.fc11.i586
-libpurple-2.6.6-1.fc11.i586
+libpurple-2.6.6-2.fc11.i586
-nspr-4.8.2-1.fc11.i586
+nspr-4.8.4-1.3.fc11.i586
-nss-3.12.5-3.fc11.i586
+nss-3.12.6-1.2.fc11.i586
-nss-softokn-freebl-3.12.5-3.fc11.i586
+nss-softokn-freebl-3.12.6-1.2.fc11.i586
-ohm-0.1.1-9.39.20091215git.fc11.i586
+olpc-powerd-12-1.fc11.i586
12:35 p.m.
chris wrote:
http://wiki.laptop.org/go/F11_for_1.5
http://build.laptop.org/10.2.0/os112
Compressed image size: 678.89mb (+0.16mb since build 111)
Description of changes in this build:
* Switch from ohmd to powerd
needless to say, this switch is a big change. please report your
experiences with powerd on XO-1.5, especially the negatives, ASAP.
and while it's a feature that powerd is pretty easy to reconfigure,
testing with the supplied default configuration is especially
important right now, since it's likely very similar to what many
thousands of kids will be using sometime soon.
paul
=---------------------
paul fox, pgf(a)laptop.org
1:52 p.m.
please report your experiences with powerd on XO-1.5
I've been using powerd all along on the XO-1 on those builds where it
was available. Powerd allows me to set the timeouts the way I like them
-- MUCH longer than the ones in ohm's default. Cannot say that any
"negatives" have disturbed me. [Just now the screen dimmed on the
XO-1.5 during a 600 MB download via ethernet (to let me know that
eventually the system would suspend, if I did not intervene in the
meantime) -- so I pressed <shift> on the keyboard (and thereby forced
the countdown-to-suspend to begin all over again).]
mikus
3:24 p.m.
mikus wrote:
> please report your experiences with powerd on XO-1.5
I've been using powerd all along on the XO-1 on those builds where it
was available. Powerd allows me to set the timeouts the way I like them
-- MUCH longer than the ones in ohm's default. Cannot say that any
"negatives" have disturbed me. [Just now the screen dimmed on the
XO-1.5 during a 600 MB download via ethernet (to let me know that
eventually the system would suspend, if I did not intervene in the
meantime) -- so I pressed <shift> on the keyboard (and thereby forced
the countdown-to-suspend to begin all over again).]
note to others: mikus is describing non-default behavior. the
default behavior is for the CPU to suspend after about 15 seconds
of inactivity. 45 seconds after that, the system will wake to dim
the screen. 3 minutes later, the screen will be blanked, and the
system will sleep. these are the settings that we'd most like
testing with. feedback on the durations of the timers themselves
would also be interesting, though finding bugs is moreso.
paul
=---------------------
paul fox, pgf(a)laptop.org
4:13 p.m.
On Fri, Mar 12, 2010 at 4:24 PM, Paul Fox <pgf(a)laptop.org> wrote:
note to others: mikus is describing non-default behavior. the
default behavior is for the CPU to suspend after about 15 seconds
of inactivity.
And I assume powerd should play nice with the wol settings?
I am somewhat intrigued by the behaviour I see around
http://dev.laptop.org/ticket/10058 -- one of the (subjective)
impressions I have is that if the download is steady, there is no
problem. It keeps waking up for tiny amounts of time.
If the download gets more choppy, trickle-y, in one of the gaps the
machine misses the WOL and goes to deep sleep.
Might be a race?
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
4:17 p.m.
martin wrote:
On Fri, Mar 12, 2010 at 4:24 PM, Paul Fox <pgf(a)laptop.org>
wrote:
> note to others: mikus is describing non-default behavior. the
> default behavior is for the CPU to suspend after about 15 seconds
> of inactivity.
And I assume powerd should play nice with the wol settings?
in theory.
I am somewhat intrigued by the behaviour I see around
http://dev.laptop.org/ticket/10058 -- one of the (subjective)
impressions I have is that if the download is steady, there is no
problem. It keeps waking up for tiny amounts of time.
If the download gets more choppy, trickle-y, in one of the gaps the
machine misses the WOL and goes to deep sleep.
Might be a race?
hmm. it's not impossible. did you see this on os111?
is that trac'ed?
paul
=---------------------
paul fox, pgf(a)laptop.org
6:23 p.m.
On 12 March 2010 16:13, Martin Langhoff <martin.langhoff(a)gmail.com> wrote:
I am somewhat intrigued by the behaviour I see around
http://dev.laptop.org/ticket/10058 -- one of the (subjective)
impressions I have is that if the download is steady, there is no
problem. It keeps waking up for tiny amounts of time.
Last time I tried, WOL was not reliable.
Trivial way to reproduce one problem:
http://dev.laptop.org/ticket/9960
I haven't tested recently, but I don't recall seeing any changes in this area.
If you continually ping an (inactive) XO with autosuspend enabled (at
the regular ping interval) does it now survive for more than an hour?
Daniel
6:14 p.m.
On Fri, Mar 12, 2010 at 06:23:15PM -0600, Daniel Drake wrote:
If you continually ping an (inactive) XO with autosuspend enabled
(at
the regular ping interval) does it now survive for more than an hour?
It works until the ARP cache of the pinging host dries up, then the ARP
queries emitted are not seen by the laptop.
Laptop will also get into a mode where the wireless LED goes off at the
same time the power LED goes off; when that happens, the next keyboard
wake will reassociate with the access point within about a minute.
Here's a test with a XO-1.5 C1 with build 112, no changes to powerd
configuration, with ARP cache preloaded on the pinging host, with the
laptop booted at the same time the ping is begun:
host:~$ ping -a -n quozl-l
PING quozl-l.lan (10.0.0.164) 56(84) bytes of data.
64 bytes from 10.0.0.164: icmp_seq=75 ttl=64 time=12.2 ms
64 bytes from 10.0.0.164: icmp_seq=76 ttl=64 time=4.23 ms
64 bytes from 10.0.0.164: icmp_seq=77 ttl=64 time=2.93 ms
64 bytes from 10.0.0.164: icmp_seq=78 ttl=64 time=2.20 ms
64 bytes from 10.0.0.164: icmp_seq=79 ttl=64 time=2.32 ms
64 bytes from 10.0.0.164: icmp_seq=80 ttl=64 time=3.10 ms
64 bytes from 10.0.0.164: icmp_seq=81 ttl=64 time=2.90 ms
64 bytes from 10.0.0.164: icmp_seq=82 ttl=64 time=2.93 ms
64 bytes from 10.0.0.164: icmp_seq=83 ttl=64 time=2.36 ms
64 bytes from 10.0.0.164: icmp_seq=84 ttl=64 time=3.11 ms
64 bytes from 10.0.0.164: icmp_seq=85 ttl=64 time=2.69 ms
64 bytes from 10.0.0.164: icmp_seq=86 ttl=64 time=2.31 ms
64 bytes from 10.0.0.164: icmp_seq=87 ttl=64 time=2.29 ms
64 bytes from 10.0.0.164: icmp_seq=88 ttl=64 time=2.46 ms
(at this point the power LED flickered off briefly, an idle suspend
event followed by a wake on LAN),
64 bytes from 10.0.0.164: icmp_seq=89 ttl=64 time=344 ms
64 bytes from 10.0.0.164: icmp_seq=90 ttl=64 time=2.37 ms
64 bytes from 10.0.0.164: icmp_seq=91 ttl=64 time=2.30 ms
64 bytes from 10.0.0.164: icmp_seq=92 ttl=64 time=2.56 ms
64 bytes from 10.0.0.164: icmp_seq=93 ttl=64 time=2.13 ms
64 bytes from 10.0.0.164: icmp_seq=94 ttl=64 time=2.25 ms
64 bytes from 10.0.0.164: icmp_seq=95 ttl=64 time=2.14 ms
64 bytes from 10.0.0.164: icmp_seq=96 ttl=64 time=2.16 ms
64 bytes from 10.0.0.164: icmp_seq=97 ttl=64 time=2.12 ms
64 bytes from 10.0.0.164: icmp_seq=98 ttl=64 time=2.28 ms
64 bytes from 10.0.0.164: icmp_seq=99 ttl=64 time=2.21 ms
(at this point the wireless LED flashed a few times, a NetworkManager
access point scan event),
64 bytes from 10.0.0.164: icmp_seq=100 ttl=64 time=334 ms
64 bytes from 10.0.0.164: icmp_seq=101 ttl=64 time=45.4 ms
64 bytes from 10.0.0.164: icmp_seq=102 ttl=64 time=2.42 ms
64 bytes from 10.0.0.164: icmp_seq=103 ttl=64 time=2.29 ms
64 bytes from 10.0.0.164: icmp_seq=104 ttl=64 time=2.27 ms
64 bytes from 10.0.0.164: icmp_seq=105 ttl=64 time=2.20 ms
64 bytes from 10.0.0.164: icmp_seq=106 ttl=64 time=2.27 ms
64 bytes from 10.0.0.164: icmp_seq=107 ttl=64 time=2.19 ms
(at this point the power LED and wireless LED both went out, and the
wake on LAN is not happening ... the laptop has to be manually woken).
--
James Cameron
http://quozl.linux.org.au/
6:34 p.m.
i've been thinking about this problem, and i'm not sure i
understand how seamless network connectivity is _supposed_ to
work, in the face of suspend and wake-on-lan.
two cases, involving host "H" and xo laptop "X".
case 1:
"H" "X"
ping -->
ping response <--
[ "X" sleeps ]
ping -->
[ "X" wakes ]
ping response <--
...and all is happy.
case 2:
"H" "X"
ping -->
ping response <--
ping -->
[ "X" receives ping, but before "X" replies, "X" sleeps ]
no response
... "H" is unhappy. "X" will respond, eventually, after
"X"
wakes. i.e., far too late.
failure cases similar to the above can be imagined for "real"
(i.e., non-ping) traffic -- network protocols are asymmetric
by nature -- one side requests, the other responds.
how exactly do we think this is supposed to work? as far as i
can see, "wake-on-lan" is only half the solution. don't we also
need a "don't-go-to-sleep-because-i-still-might-have
something-to-send" feature?
or, more realistically, i think at the least we need a mode like
one of the following:
- "no tcp (or ping or dns or arp or ... ) packets in the
last NN seconds means i'm idle" means it's okay to sleep
or:
- "no tcp sessions open at all" means it's okay to sleep
a simple "how busy is the network?" mode won't be sufficient, i
don't think.
paul
james wrote:
On Fri, Mar 12, 2010 at 06:23:15PM -0600, Daniel Drake wrote:
> If you continually ping an (inactive) XO with autosuspend enabled (at
> the regular ping interval) does it now survive for more than an hour?
It works until the ARP cache of the pinging host dries up, then the ARP
queries emitted are not seen by the laptop.
Laptop will also get into a mode where the wireless LED goes off at the
same time the power LED goes off; when that happens, the next keyboard
wake will reassociate with the access point within about a minute.
Here's a test with a XO-1.5 C1 with build 112, no changes to powerd
configuration, with ARP cache preloaded on the pinging host, with the
laptop booted at the same time the ping is begun:
host:~$ ping -a -n quozl-l
PING quozl-l.lan (10.0.0.164) 56(84) bytes of data.
64 bytes from 10.0.0.164: icmp_seq=75 ttl=64 time=12.2 ms
64 bytes from 10.0.0.164: icmp_seq=76 ttl=64 time=4.23 ms
64 bytes from 10.0.0.164: icmp_seq=77 ttl=64 time=2.93 ms
64 bytes from 10.0.0.164: icmp_seq=78 ttl=64 time=2.20 ms
64 bytes from 10.0.0.164: icmp_seq=79 ttl=64 time=2.32 ms
64 bytes from 10.0.0.164: icmp_seq=80 ttl=64 time=3.10 ms
64 bytes from 10.0.0.164: icmp_seq=81 ttl=64 time=2.90 ms
64 bytes from 10.0.0.164: icmp_seq=82 ttl=64 time=2.93 ms
64 bytes from 10.0.0.164: icmp_seq=83 ttl=64 time=2.36 ms
64 bytes from 10.0.0.164: icmp_seq=84 ttl=64 time=3.11 ms
64 bytes from 10.0.0.164: icmp_seq=85 ttl=64 time=2.69 ms
64 bytes from 10.0.0.164: icmp_seq=86 ttl=64 time=2.31 ms
64 bytes from 10.0.0.164: icmp_seq=87 ttl=64 time=2.29 ms
64 bytes from 10.0.0.164: icmp_seq=88 ttl=64 time=2.46 ms
(at this point the power LED flickered off briefly, an idle suspend
event followed by a wake on LAN),
64 bytes from 10.0.0.164: icmp_seq=89 ttl=64 time=344 ms
64 bytes from 10.0.0.164: icmp_seq=90 ttl=64 time=2.37 ms
64 bytes from 10.0.0.164: icmp_seq=91 ttl=64 time=2.30 ms
64 bytes from 10.0.0.164: icmp_seq=92 ttl=64 time=2.56 ms
64 bytes from 10.0.0.164: icmp_seq=93 ttl=64 time=2.13 ms
64 bytes from 10.0.0.164: icmp_seq=94 ttl=64 time=2.25 ms
64 bytes from 10.0.0.164: icmp_seq=95 ttl=64 time=2.14 ms
64 bytes from 10.0.0.164: icmp_seq=96 ttl=64 time=2.16 ms
64 bytes from 10.0.0.164: icmp_seq=97 ttl=64 time=2.12 ms
64 bytes from 10.0.0.164: icmp_seq=98 ttl=64 time=2.28 ms
64 bytes from 10.0.0.164: icmp_seq=99 ttl=64 time=2.21 ms
(at this point the wireless LED flashed a few times, a NetworkManager
access point scan event),
64 bytes from 10.0.0.164: icmp_seq=100 ttl=64 time=334 ms
64 bytes from 10.0.0.164: icmp_seq=101 ttl=64 time=45.4 ms
64 bytes from 10.0.0.164: icmp_seq=102 ttl=64 time=2.42 ms
64 bytes from 10.0.0.164: icmp_seq=103 ttl=64 time=2.29 ms
64 bytes from 10.0.0.164: icmp_seq=104 ttl=64 time=2.27 ms
64 bytes from 10.0.0.164: icmp_seq=105 ttl=64 time=2.20 ms
64 bytes from 10.0.0.164: icmp_seq=106 ttl=64 time=2.27 ms
64 bytes from 10.0.0.164: icmp_seq=107 ttl=64 time=2.19 ms
(at this point the power LED and wireless LED both went out, and the
wake on LAN is not happening ... the laptop has to be manually woken).
--
James Cameron
http://quozl.linux.org.au/
_______________________________________________
olpc mailing list
olpc(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/olpc
=---------------------
paul fox, pgf(a)laptop.org
6:38 p.m.
On Sun, Mar 14, 2010 at 6:34 PM, Paul Fox <pgf(a)laptop.org> wrote:
how exactly do we think this is supposed to work? as far as i
can see, "wake-on-lan" is only half the solution. don't we also
need a "don't-go-to-sleep-because-i-still-might-have
something-to-send" feature?
I agree -- I suspect our WOL wakes up for a period that is way too
short. Unsure who controls that though...
cheers,
m
--
martin.langhoff(a)gmail.com
martin(a)laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
8:09 p.m.
On Sun, Mar 14, 2010 at 07:34:14PM -0400, Paul Fox wrote:
i've been thinking about this problem, and i'm not sure i
understand how seamless network connectivity is _supposed_ to
work, in the face of suspend and wake-on-lan.
Classic Wake on LAN is an entirely different technology to what we are
trying.
What we want is most of the time spent in suspend, if there is no reason
to wake, and to wake if there is reason.
Reasons to wake that we are handling are:
- incoming network packet,
- user input.
Reasons to wake that we are not handling are:
- TCP timer expiry, (e.g. a retry on an active connection, where a
segment we have sent hasn't been acknowledged),
- application timer expiry (e.g. a ping from the laptop to another
host, or some other application level network timer),
And as you point out, we are probably not deferring a wake when a packet
is ready to be sent.
don't we also need a
"don't-go-to-sleep-because-i-still-might-have
something-to-send" feature?
Heh.
a simple "how busy is the network?" mode won't be
sufficient, i
don't think.
Agreed, this could be an intractable problem. It may require more
thought. You've started, let's proceed.
One workaround is to merely wake up once a minute for a second or
two. This will allow TCP to emit what it should, and allow user space
processes to get through their event or timing loops.
--
James Cameron
http://quozl.linux.org.au/
5182
days inactive
5187
days old
10 comments
6 participants
participants (6)
-
Chris Ball -
Daniel Drake -
James Cameron -
Martin Langhoff -
Mikus Grinbergs -
Paul Fox