The biggest problems I see with Wake-On-Lan:
1) Not every chip supports the same magic-packet to wake up. Some
don't use a packet, but rely on link status changes!
2) Many (most!) magic-packet formats are not routeable. Many of
them don't include
3) I know of no network gear that can automatically tell that a
system is down or hibernating and send a magic packet to wake up a
system. (Not saying such gear doesn't exist, just that I don't know of it.)
4) Hence, apart from special use cases, on private networks,
magic-packet is basically useless. You can't use it with hibernate or
sleep to automatically suspend machines and wake them back up when they
need to be servicing work.
Without #4, there is no tangible use case. Item #4 IMO requires special
work -- it requires the NIC to recognize directed ARP traffic and use
such to wake up the machine. Because of #1 above, this doesn't work
usefully with current equipment.
If folks are using Wake-On-Lan with Windows or Linux or other platforms,
I'd like to hear a lot more about the use cases... I'm not adverse to
spending time to make this work better, but until I understand what
people want from it (and whether hardware can achieve it), I remain
rather conservative about spending time implementing WoL.
The use case that I think most people want is #4. (Let your
fileservers go into sleep mode until they are called upon to perform
some real work...)
- Garrett
Randy Fishel wrote:
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]
_______________________________________________
networking-discuss mailing list
[email protected]
