radio off guarantee?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

James Cameron-2
I'm taking a few units to demo at a radiotelescope open day in Parkes,
NSW, Australia, this weekend.

I've been asked to ensure the radios are off, since the telescope will
be observing at the time, in the spectrum the laptops emit in.

Is this sequence sufficient:

- rename usb8xxx.ko to usb8xxx.disabled,
- power down,
- remove battery and AC adaptor,
- power up.

On the B4, this prevents the two left-hand LEDs from lighting ... the
keyhole LED and the Star Wars TIE fighter LED.  But on build 566 at
least the X server does not start.  "Xlib: connection to ":0.0" refused
by server".

Workaround is to put usb8xxx.ko back into place, modprobe it, and use
Control/Alt/Backspace on the X server console.  But then the wireless is
on.  ;-}

--
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/

Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

bernie
Subject:   Re: radio off guarantee?

To:        James Cameron <quozl at laptop.org>,devel at lists.laptop.org

Cc:        

Bcc:      

-=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=-

James Cameron wrote:



> - rename usb8xxx.ko to usb8xxx.disabled,

> - power down,

> - remove battery and AC adaptor,

> - power up.

>

> On the B4, this prevents the two left-hand LEDs from lighting ... the

> keyhole LED and the Star Wars TIE fighter LED.  But on build 566 at

> least the X server does not start.  "Xlib: connection to ":0.0" refused

> by server".



I don't see how removing the usb8xxx kernel driver may affect X client

connections.  I'd say the two have to be independent.



Also, I'm a bit confused: the error message you see does not mean that X

server is not starting.  On the countrary, you only get it when the

server is running and you try to start a client without proper

authorization.



Where do you see this message?  Check for $XAUTHORITY: it should point

to a file containing the xauth cookie.



--

   //  Bernardo Innocenti - http://www.codewiz.org/

 \X/ One Laptop Per Child - http://www.laptop.org/


Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

James Cameron-2
Low priority ... removing the usb8xxx kernel driver is not a
conventional use case.

On Mon, Sep 17, 2007 at 10:32:35PM -0400, Bernardo Innocenti wrote:
> I don't see how removing the usb8xxx kernel driver may affect X client
> connections.  I'd say the two have to be independent.

I agree.  But it happens.  I've reproduced it.  I'll try some later
builds though.  566 is a bit old now.  Sorry.

> Where do you see this message?

By pressing Control/Alt/F2.  The X server /usr/bin/X has file descriptor
2 (stderr) anchored to /dev/tty2, per "ls -l /proc/`pgrep X`/fd" ...
therefore the second text console contains the message, repeating.

> Check for $XAUTHORITY: it should point to a file containing the xauth
> cookie.

Got it.  /proc/`pgrep X`/environ contains XAUTHORITY which points to
/home/olpc/.Xauthority last changed several days ago, which contains a
hostname of xo-05-27-F1.localdomain, but the current /bin/hostname
output is "localhost.localdomain" ... so I conjecture that removing the
wireless kernel driver results in the hostname not being the same as
what it was before.

--
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/

Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

Javier Cardona
Don't have a box with me right now to confirm, but this command
sequence used to turn off the radio:

# killall NetworkManager
# iwpriv eth0 radiooff

Javier

On 9/17/07, James Cameron <quozl at laptop.org> wrote:

> Low priority ... removing the usb8xxx kernel driver is not a
> conventional use case.
>
> On Mon, Sep 17, 2007 at 10:32:35PM -0400, Bernardo Innocenti wrote:
> > I don't see how removing the usb8xxx kernel driver may affect X client
> > connections.  I'd say the two have to be independent.
>
> I agree.  But it happens.  I've reproduced it.  I'll try some later
> builds though.  566 is a bit old now.  Sorry.
>
> > Where do you see this message?
>
> By pressing Control/Alt/F2.  The X server /usr/bin/X has file descriptor
> 2 (stderr) anchored to /dev/tty2, per "ls -l /proc/`pgrep X`/fd" ...
> therefore the second text console contains the message, repeating.
>
> > Check for $XAUTHORITY: it should point to a file containing the xauth
> > cookie.
>
> Got it.  /proc/`pgrep X`/environ contains XAUTHORITY which points to
> /home/olpc/.Xauthority last changed several days ago, which contains a
> hostname of xo-05-27-F1.localdomain, but the current /bin/hostname
> output is "localhost.localdomain" ... so I conjecture that removing the
> wireless kernel driver results in the hostname not being the same as
> what it was before.
>
> --
> James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>


--
Javier Cardona
cozybit Inc.

Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

Hal Murray-2
In reply to this post by James Cameron-2

What are the rules about WiFi on airplanes?  Do we need a solid way to turn
off the RF before it's OK to use an XO on an airplane?


Suppose I'm someplace where I don't expect or want to do any mesh networking.
 How much would turning off the radio help battery life?



--
These are my opinions, not necessarily my employer's.  I hate spam.




Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

James Cameron-2
On Mon, Sep 17, 2007 at 09:22:32PM -0700, Hal Murray wrote:
> What are the rules about WiFi on airplanes?

Check with your airplane.

> Do we need a solid way to turn off the RF before it's OK to use an XO
> on an airplane?

Our target market usually won't have this problem.

> Suppose I'm someplace where I don't expect or want to do any mesh
> networking.
> How much would turning off the radio help battery life?

Last I checked, the effect was very small.  There will be occasional
scans as the unit hunts around for nearby radios.  One could save more
by making those scans back off rather than provide a UI element.

--
James Cameron    mailto:quozl at us.netrek.org     http://quozl.netrek.org/

Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

James Cameron-2
In reply to this post by Javier Cardona
On 18/09/2007, at 2:20 PM, Javier Cardona wrote:
> Don't have a box with me right now to confirm, but this command
> sequence used to turn off the radio:
>
> # killall NetworkManager

This seems to.  The LEDs are extinguished.  However it turns back on  
after the next reboot.

> # iwpriv eth0 radiooff

This generates "Invalid command : radiooff" on build 566.

--
James Cameron


Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

bernie
In reply to this post by James Cameron-2
James Cameron wrote:

> By pressing Control/Alt/F2.  The X server /usr/bin/X has file descriptor
> 2 (stderr) anchored to /dev/tty2, per "ls -l /proc/`pgrep X`/fd" ...
> therefore the second text console contains the message, repeating.

This behavior comes from olpc-dm... Actually I don't like it that
much... I preferred $HOME/.xsession-errors.


> Got it.  /proc/`pgrep X`/environ contains XAUTHORITY which points to
> /home/olpc/.Xauthority last changed several days ago, which contains a
> hostname of xo-05-27-F1.localdomain, but the current /bin/hostname
> output is "localhost.localdomain" ... so I conjecture that removing the
> wireless kernel driver results in the hostname not being the same as
> what it was before.

Ah, good catch!

But it's suspicious that .Xauthority is that old, because a fresh one
should be created each time X starts.  Is the hwclock set correctly?

In latest builds, the cookies moved to ~/.serverauth.$$.

I dunno why we put the PID there.  It litters the home directory.
Auth cookies are unique per-display, so ".xserverauth.$DISPLAY"
would have been a better name.

--
   //  Bernardo Innocenti - http://www.codewiz.org/
 \X/ One Laptop Per Child - http://www.laptop.org/

Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

John Watlington
In reply to this post by James Cameron-2

>> Suppose I'm someplace where I don't expect or want to do any mesh
>> networking.
>> How much would turning off the radio help battery life?
>
> Last I checked, the effect was very small.  There will be occasional
> scans as the unit hunts around for nearby radios.  One could save more
> by making those scans back off rather than provide a UI element.

We see 700 to 800 mW consumed by the mesh interface, and as with most
WiFi interfaces, receiving consumes as much power as transmitting.

While it makes sense to turn off the wireless networking interface on  
developer
machines, we are hesitant to add this to the UI.  We are really  
relying on laptops
to extend the mesh away from the school.

wad


Reply | Threaded
Open this post in threaded view
|

Power envelope (was Re: radio off guarantee?)

Mike C. Fletcher-2
John Watlington wrote:

>>> Suppose I'm someplace where I don't expect or want to do any mesh
>>> networking.
>>> How much would turning off the radio help battery life?
>>>      
>> Last I checked, the effect was very small.  There will be occasional
>> scans as the unit hunts around for nearby radios.  One could save more
>> by making those scans back off rather than provide a UI element.
>>    
>
> We see 700 to 800 mW consumed by the mesh interface, and as with most
> WiFi interfaces, receiving consumes as much power as transmitting.
>  
Isn't that about 1/2 of our total power budget?  .7 to .8 W on a < 2W
machine?  I'd thought the Marvell chip was supposed to be down in the
.3W range.  Obviously haven't been following the hardware closely
enough.  (http://wiki.laptop.org/go/Power_Management is where I got the
.3W idea).  Is that .7W something we'll be able to bring down with
software to reduce collisions or the like?  University of Toronto's
system's group has algorithms that optimise for power savings by
reducing collisions, if that would help.

 From the same page, we'd only last 20 hours at ~.7W draw with a *full*
charge (and with hand-charging a full charge likely won't be there,
especially at the end of the day), which means that the machines are
going to be dead each morning (having drained their batteries keeping up
an unused network all night).  With a 40 hour period (.3W) we were
possibly going to have some juice left in the morning (need to be at >
1/4 power when you shut off for the night), but that becomes less likely
with a 20 hour period (need to be at >1/2 power when you shut off for
the night).
> While it makes sense to turn off the wireless networking interface on  
> developer
> machines, we are hesitant to add this to the UI.  We are really  
> relying on laptops
> to extend the mesh away from the school.
>  
If we really are spending half our power budget on the mesh network I
would imagine that kids will want to be able to turn it off.  Yes,
meshing is good, but if you could double your battery life while you're
at home reading, that would be very worthwhile too.  What about *only*
keeping the mesh up (continuously) if you are actually routing packets?

That is, wake up the mesh interface every few minutes, check to see if
your new routing structure makes you a link that is desirable, and only
stay on if that's the case.  (I realise I'm talking about long-term
projects here).  You'd need the machines to be able to queue up messages
to go out so that they could leap at the request and say "yes, please
stay up" when a linking machine pops on to check for need (implying from
activity requests on the local machine would be likely be sufficient,
but a simple UI might be workable too).  If the network is inactive for
X period, go into periodic sleep mode again to save energy.

Even if you had to wake up the processor for a few seconds to run the
code that decides whether to sleep, it's only about double the power of
running the mesh for those seconds, and it could save you the entire
power budget for a few minutes.  Of course, in the field it may be that
the mesh is so densely used that it's never going to go down with that
algorithm, but it seems like something we need to investigate if we
really are losing that much power to the interface.

Just a thought,
Mike

--
________________________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://www.vrplumber.com
  http://blog.vrplumber.com


Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

linaccess@yokoy.de
In reply to this post by James Cameron-2
moin,

On Tue, 18 Sep 2007 14:42:51 +1000
James Cameron <quozl at laptop.org> wrote:

> > Do we need a solid way to turn off the RF before it's OK to use an XO
> > on an airplane?
>
> Our target market usually won't have this problem.

Yes, but the developers need a solid way to switch of the RF. The Test XO target market are developers and sometimes they travel by air.

Javier wrote:
# killall NetworkManager
# iwpriv eth0 radiooff

How could we ensure not bringing up the RF at boot time? Which file takes care of this at fedora systems?


Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

Hal Murray-2
In reply to this post by John Watlington

> We see 700 to 800 mW consumed by the mesh interface, and as with most
> WiFi interfaces, receiving consumes as much power as transmitting.

Crazy thought dept...

How long does it take to turn the receiver on?  If all the clocks in a mesh
were synchronized, would it make sense to turn all the receivers off during
idle periods and turn them on for say 100 ms on the second boundary to see if
there was any traffic?  (I'm assuming the transmit side would cooperate.)



--
These are my opinions, not necessarily my employer's.  I hate spam.




Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

Dan Williams-4
In reply to this post by linaccess@yokoy.de
On Tue, 2007-09-18 at 18:52 +0200, linaccess at yokoy.de wrote:

> moin,
>
> On Tue, 18 Sep 2007 14:42:51 +1000
> James Cameron <quozl at laptop.org> wrote:
>
> > > Do we need a solid way to turn off the RF before it's OK to use an XO
> > > on an airplane?
> >
> > Our target market usually won't have this problem.
>
> Yes, but the developers need a solid way to switch of the RF. The Test XO target market are developers and sometimes they travel by air.
>
> Javier wrote:
> # killall NetworkManager
> # iwpriv eth0 radiooff
>
> How could we ensure not bringing up the RF at boot time? Which file takes care of this at fedora systems?

Add a hardware killswitch if you want to be 100% sure.  There is no
single file that "takes care of this" on any system really.  But if you
remove the kernel modules, firmware will not get uploaded to the card,
and therefore the radio will essentially do nothing AFAIK.

Dan



Reply | Threaded
Open this post in threaded view
|

Power envelope (was Re: radio off guarantee?)

Jim Gettys-3
In reply to this post by Mike C. Fletcher-2
On Tue, 2007-09-18 at 12:12 -0400, Mike C. Fletcher wrote:

> John Watlington wrote:
> >>> Suppose I'm someplace where I don't expect or want to do any mesh
> >>> networking.
> >>> How much would turning off the radio help battery life?
> >>>      
> >> Last I checked, the effect was very small.  There will be occasional
> >> scans as the unit hunts around for nearby radios.  One could save more
> >> by making those scans back off rather than provide a UI element.
> >>    
> >
> > We see 700 to 800 mW consumed by the mesh interface, and as with most
> > WiFi interfaces, receiving consumes as much power as transmitting.
> >  
> Isn't that about 1/2 of our total power budget?  .7 to .8 W on a < 2W
> machine?  I'd thought the Marvell chip was supposed to be down in the
> .3W range.  Obviously haven't been following the hardware closely
> enough.  (http://wiki.laptop.org/go/Power_Management is where I got the
> .3W idea).  Is that .7W something we'll be able to bring down with
> software to reduce collisions or the like?  University of Toronto's
> system's group has algorithms that optimise for power savings by
> reducing collisions, if that would help.

The current firmware has not yet been optimized, and is consuming much
more power than it should once that is done.  And future wireless will
also help.
                           - Jim

--
Jim Gettys
One Laptop Per Child



Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

Richard A. Smith
In reply to this post by John Watlington
John Watlington wrote:

> While it makes sense to turn off the wireless networking interface on  
> developer

So there's a slight problem with powering off the wireless interface
from an electrical standpoint.  You can't.
At least not if you want a working system.

WLAN_EN controls WLAN_3.3V. +3.3V is derived from WLAN_3.3V.  So if you
drop WLAN_3.3V you lose +3.3V and you also lose:

VDDIO on the LX700
Pullups on the PCI bus.
Pullups on the jtag lines
Supply voltages for COREPLL, GLPLL, and DOTPLL on the LX700
Power supply to the LX700 Therm alarm circuits
Power supply to the system clock chip.

And lots of other stuff...you get the idea.  System no workie.

That leaves 3 alternatives:

1 Don't load the wlan firmware.
2 Load the firmware and tell wlan xmit to shutdown
3 Hold the WLAN module in reset.

#3 Can be done via the EC but there's currently not a command to _hold_
it in reset.  There is a reset WLAN command which will strobe the reset
line for 1ms.  I can add enable/disable reset commands if 1 and 2 are
not viable.

--
Richard Smith  <richard at laptop.org>
One Laptop Per Child


Reply | Threaded
Open this post in threaded view
|

radio off guarantee?

Dan Williams-4
On Tue, 2007-09-18 at 15:33 -0400, Richard A. Smith wrote:

> John Watlington wrote:
>
> > While it makes sense to turn off the wireless networking interface on  
> > developer
>
> So there's a slight problem with powering off the wireless interface
> from an electrical standpoint.  You can't.
> At least not if you want a working system.
>
> WLAN_EN controls WLAN_3.3V. +3.3V is derived from WLAN_3.3V.  So if you
> drop WLAN_3.3V you lose +3.3V and you also lose:
>
> VDDIO on the LX700
> Pullups on the PCI bus.
> Pullups on the jtag lines
> Supply voltages for COREPLL, GLPLL, and DOTPLL on the LX700
> Power supply to the LX700 Therm alarm circuits
> Power supply to the system clock chip.
>
> And lots of other stuff...you get the idea.  System no workie.
>
> That leaves 3 alternatives:
>
> 1 Don't load the wlan firmware.
> 2 Load the firmware and tell wlan xmit to shutdown
> 3 Hold the WLAN module in reset.
>
> #3 Can be done via the EC but there's currently not a command to _hold_
> it in reset.  There is a reset WLAN command which will strobe the reset
> line for 1ms.  I can add enable/disable reset commands if 1 and 2 are
> not viable.

1 and 2 are certainly viable and should be the preferred methods I
think.  Note that right now trying to rmmod usb8xxx panics the kernel
for some reason.

Dan



Reply | Threaded
Open this post in threaded view
|

Power envelope (was Re: radio off guarantee?)

Dan Williams-4
In reply to this post by Mike C. Fletcher-2
On Tue, 2007-09-18 at 12:12 -0400, Mike C. Fletcher wrote:

> John Watlington wrote:
> >>> Suppose I'm someplace where I don't expect or want to do any mesh
> >>> networking.
> >>> How much would turning off the radio help battery life?
> >>>      
> >> Last I checked, the effect was very small.  There will be occasional
> >> scans as the unit hunts around for nearby radios.  One could save more
> >> by making those scans back off rather than provide a UI element.
> >>    
> >
> > We see 700 to 800 mW consumed by the mesh interface, and as with most
> > WiFi interfaces, receiving consumes as much power as transmitting.
> >  
> Isn't that about 1/2 of our total power budget?  .7 to .8 W on a < 2W
> machine?  I'd thought the Marvell chip was supposed to be down in the
> .3W range.  Obviously haven't been following the hardware closely

The .3W number is applicable to _infrastructure_ mode with the Marvell
part, because the device (like most 802.11 devices) can go into
powersave poll mode when in a BSS.  In ad-hoc situations, of course,
there is no central controller buffering frames and sending out the TIM
and therefore you have to have your RX pieces powered on most of the
time to receive traffic from other stations, or you start missing frames
entirely.  You can't use the same powersave algorithms in a mesh (or
adhoc even) network as you can use in an infrastructure network.  Of
course everything in the world right now pretty much uses infrastructure
networks, and so the powersave algorithms are tuned for that.  But mesh
requires new powersave algorithms, or at least an implementation of
existing algorithms.  There's enough work getting the mesh implemented
and working well right now without throwing power algorithms into the
mix.

Dan

> enough.  (http://wiki.laptop.org/go/Power_Management is where I got the
> .3W idea).  Is that .7W something we'll be able to bring down with
> software to reduce collisions or the like?  University of Toronto's
> system's group has algorithms that optimise for power savings by
> reducing collisions, if that would help.
>
>  From the same page, we'd only last 20 hours at ~.7W draw with a *full*
> charge (and with hand-charging a full charge likely won't be there,
> especially at the end of the day), which means that the machines are
> going to be dead each morning (having drained their batteries keeping up
> an unused network all night).  With a 40 hour period (.3W) we were
> possibly going to have some juice left in the morning (need to be at >
> 1/4 power when you shut off for the night), but that becomes less likely
> with a 20 hour period (need to be at >1/2 power when you shut off for
> the night).
> > While it makes sense to turn off the wireless networking interface on  
> > developer
> > machines, we are hesitant to add this to the UI.  We are really  
> > relying on laptops
> > to extend the mesh away from the school.
> >  
> If we really are spending half our power budget on the mesh network I
> would imagine that kids will want to be able to turn it off.  Yes,
> meshing is good, but if you could double your battery life while you're
> at home reading, that would be very worthwhile too.  What about *only*
> keeping the mesh up (continuously) if you are actually routing packets?
>
> That is, wake up the mesh interface every few minutes, check to see if
> your new routing structure makes you a link that is desirable, and only
> stay on if that's the case.  (I realise I'm talking about long-term
> projects here).  You'd need the machines to be able to queue up messages
> to go out so that they could leap at the request and say "yes, please
> stay up" when a linking machine pops on to check for need (implying from
> activity requests on the local machine would be likely be sufficient,
> but a simple UI might be workable too).  If the network is inactive for
> X period, go into periodic sleep mode again to save energy.
>
> Even if you had to wake up the processor for a few seconds to run the
> code that decides whether to sleep, it's only about double the power of
> running the mesh for those seconds, and it could save you the entire
> power budget for a few minutes.  Of course, in the field it may be that
> the mesh is so densely used that it's never going to go down with that
> algorithm, but it seems like something we need to investigate if we
> really are losing that much power to the interface.
>
> Just a thought,
> Mike
>