On Sat, 19 Sep 2009, James Carlson wrote:
> Trygve Laugstøl wrote:
> > James Carlson wrote:
> >> I think the lack of support for it reflects a lack of a tangible usage
> >> case more than anything else. If there were someone with a solid need,
> >> and someone to work on it, it might get done. A lot more effort has
> >> been put into generic low-power modes than into special mechanisms like
> >> "wake on LAN."
> >
> > Is WoL really a special mechanism?
>
> I think it is, yes.
IMO, it is both special and not. From the hardware perspective, it
isn't any different than pression the power button (or a key, etc.) to
get the machine working again. It is, in that it requires special
configuration to be usable.
>
> > Isn't sending a WoL packet just a way to transition a machine from
> > one of the "off" states to running over the network? It also seems
> > quite standardized from what I can tell.
It is a "special" packet that causes the generation of an internal
hardware event (PME). So the for starters, it requires that a machine
has some ability to do something with the PME, and the software
running prior to that occurance configuring the device so that it can
see this "special" packet (I use "special", as Jim presents below, it
is non-trivial to what the packet actually means).
>
> The "magic packet" hack is one part of it. Not all senders (in fact,
> very *FEW* senders) support that mechanism, so it's not terribly useful
> in practice. All of the WoL implementations I've seen include
> complicated -- and vendor-specific -- packet filters to determine what
> packets count as "activity" worthy of powering up the rest of the
> system, and that complexity means additional administrative interfaces
> and management.
>
> And it means special driver and hardware support to make it work. Worse
> still, you're chained to whatever that hardware happens to support, and
> if the OS is different, you're out of luck. For example, if your
> network runs IPv6, but the card itself doesn't have filtering for IPv6
> packets, forget it.
>
> And it has essentially non-existent security. For some applications,
> that might not matter. For others, it's a pretty serious flaw.
>
> And if your OS dies for some reason (say, if you're using this in a lab
> where you're testing software), you'll be completely out of luck. WoL
> turns things on, but it doesn't turn 'em off.
>
> It's not at all simple.
Absolutely!
>
> In contrast, ordinary power-saving modes cause the system to continue
> running enough that the normal IP stack is still there, and can still
> process packets (though perhaps slowly). When the power-management
> subsystem detects that the system is busy enough to warrant a
> higher-power mode (or when a powered-off device, such as a disk, is
> needed), the system can come up the rest of the way.
>
> It's all integrated and automatic, and it works normally without special
> administration or configuration. It's a substantially better system
> architecture.
And this is the relevance to my statements w.r.t. "does OpenSolaris
support WOL". OpenSolaris doesn't care, as it _is_not_running_ in a
WOL scenario. So it is not a question of "does OpenSolaris support
WOL?", but "can OpenSolaris be used to configure WOL?" (or even "does
an OpenSolaris driver break WOL?", because bge does).
What this does mean, though, that a user might be able to enable WOL
in the BIOS, and actually have a MagicPacket generator wake a
"sleeping" (S3) machine. But results may (and probably will) vary.
>
> That's why I don't like WoL. It means special wackiness in the driver,
> and it's decidedly not general-purpose. Though it may work for some in
> particular applications, it's doomed to having warts. It looks like a
> hack to me.
>
> >> (What I recall of that case was that it was -- searching for words --
> >> "experimental" in nature. A project started now to address this issue
> >> would probably be better off starting from scratch.)
> >>
> >
> > Hm, too bad. It would be very nice (for me at least) to be able to turn
> > machines on and off as I need them.
>
> As Sebastien noted, a remote power control unit is really the way to go
> for that. It works with everything. It's highly predictable. It
> allows precise control, even if the OS becomes argumentative. Decent
> implementations include multiple access methods (including serial,
> telephone, and network), along with security controls and remote
> monitoring of power consumption and other information.
Unfortunately, using remote power control means that the machine
will always go through a normal boot (at least till reusable statefile
support is available on the particular hardware). A sleeping machine
doesn't draw that much more power than a soft-off machine, and resume
time can be quite quick. For data centers looking for the lowest
latency, in and out of S3 is more appealing.
And though I don't have the same negative sentiment as Jim, there
are lots of flaws it the entire methodology, that I am not that keen
either (otherwise, there might have been more already).
Cheers!
---- Randy
>
> Here's one such device:
>
> http://www.cdw.com/shop/products/default.aspx?EDC=1006330
>
> Bay Tech is another manufacturer. There are a few others out there.
> (I'm not sure what would work in Norway, but I'm sure such a thing is
> out there.)
>
> > I have a bunch of older, white label machines that I use to to large
> > scale test of distributed software on but I only need them now and them.
> > Too bad I don't have the knowledge to hack kernels :/ I'm willing to
> > test any solution if anyone else can develop it though!
>
> That sounds like the perfect application for a remote power control unit.
>
> --
> James Carlson 42.703N 71.076W <[email protected]>
> _______________________________________________
> networking-discuss mailing list
> [email protected]
> _______________________________________________
networking-discuss mailing list
[email protected]
