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. > 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. 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. 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. 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. 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]
