PDA

View Full Version : wake-on lan for squeezebox 1



bcc
2005-11-12, 22:34
I see that bug 1200 (wake on lan) was commited to the firmware for the squeezebox 2. I have squeezebox 1 and am interested in this functionality as well. I've tested and my server box does respond to wake on lan, if only the packet were being sent to it... Can/will this change be backported? I see there is bug 331 for the squeezebox 1, but it's still marked open (assigned).

bcc
2005-11-13, 17:58
Ok, I finally found a comment here http://forums.slimdevices.com/showthread.php?p=52396&highlight=wake#post52396 that this won't be added to squeezebox 1 firmware. Shouldn't bug 331 be marked WONTFIX then? Also I'm wondering if it's possible to achieve this effect (waking the slimserver) through a plugin instead of a firmware fix.

Michaelwagner
2005-11-13, 18:07
I'm wondering if it's possible to achieve this effect (waking the slimserver) through a plugin instead of a firmware fix.
I don't think so. Plugins plug in to the slimserver, which is presumably asleep if you're trying to wake it up.

bcc
2005-11-13, 18:30
Some of the plugins (such as graphic&font) affect what's run on the squeezebox, not the slimserver, no? Maybe a plugin, such as one that provides an internet radio station, could be hacked to provide this functionality? For example, a dummy internet radio station whose password happens to include the 16 mac addresses necessary to form a wake-on-lan packet?

Michaelwagner
2005-11-13, 18:38
Some of the plugins (such as graphic&font) affect what's run on the squeezebox
Correct. They effect what happens on the squeezebox, but they run on the server machine.

Jim
2005-11-13, 18:54
I'm right thinking the only source we don't have access to in the whole setup is the firmware source, right?

I understand Slim don't want to use resources upgrading old hardware which can only introduce problems . Be interesing if some sort of unofficial firmware appeared somewhere however, that we were told would be unsupported if we used.

pfarrell
2005-11-13, 19:01
On Sun, 2005-11-13 at 17:54 -0800, Jim wrote:
> I'm right thinking the only source we don't have access to in the whole
> setup is the firmware source, right?

Right, the microcode SDK is proprietary to the vendor that SlimDevices
bought them from, Apparently very, very expensive.

I know I just bought a SDK/eval kit for some Ember zigbee systems,
and the SDK is $13K with dongles and all sorts of anti-open source
stuff. Runs only on Windows, the cross compiler won't talk
about Linux, etc. Not a fruitful place for hobby folks
to mess about.

That said, I've watched folks talk about wake-on-lan for ages, and
I fail to see what about it is attractive. What are people
hoping to accomplish? It always looked to me as a solution
looking for a problem. Seems that getting a low power server
and leaving it on all the time, like we do with routers, etc.
makes the problem go away.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

Jim
2005-11-13, 19:23
Good point Pat. Like you I don't personally care as my server is on 25/8.

But some people do and I was only trying to contribute, and I'd like to run a firmware upgrade one day. Being a bit late in upgrading from my SlimMP3 I got my SB1 less than a week before the SB2 came out :(

Propietary this/that/whatever and expense are irrelevant when if someone smart can do something in a hex editor, or someone who works for Slim can with a management wink and upload a unoffical file somewhere.

pfarrell
2005-11-13, 19:54
On Sun, 2005-11-13 at 18:23 -0800, Jim wrote:
> Propietary this/that/whatever and expense are irrelevant when if
> someone smart can do something in a hex editor,

Well, it is just software, but writing micro-controller
code is a very specialized art. Not at all like writing
for an Intel x86. The proprietary stuff is just a barrier
to entry, requiring someone much smarter. Most of them
are hacking more widespread stuff, like PSPs or xBoxes or
routers.

> upload a unoffical file somewhere.

I'll host it on my servers, so that SD can not be aware and not
have to wink. But I think it is unlikely that anyone will
put the effort in, especially when you can just buy a used SB2.
But if someone does write such a hack, send me an email.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

bcc
2005-11-13, 19:56
I'm with Jim :). I could give Pat a bunch of justification for wake-on-lan but it sounds like that's a waste of time. Especially considering that wake-on-lan has already been justified for sb2/3. Like Jim I got an SB1 "just" before the sb2 came out. If the slimbox was sufficiently open ended, I could add wake-on-lan support myself. The marketing for the slimbox suggests that it is implemented in such an open ended fashion.

pfarrell
2005-11-13, 20:19
On Sun, 2005-11-13 at 18:56 -0800, bcc wrote:
> I could give Pat a bunch of justification for
> wake-on-lan but it sounds like that's a waste of time.

I'm not the one you'd have to convince. I just asked because
I don't remember any of the reasons folks want it.
For any version of anything.

Given the probability of any argument being sufficient
to make it happen, its just idle curiosity on my part.
There is no way I'm interested in paying either the
serious bucks when I can get a SB2 for under $200, or
taking a few hundred hours to reverse engineer it.

In the open source world, things tend to happen more
often after using honey rather than vinegar as bait.



--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

Michaelwagner
2005-11-13, 20:31
Personally, it seems to me like a feature looking for a problem.

You can do 90% of the power savings by figuring out how to spin down the hard disk and getting a temperature controlled fan.

Considering that the implementation of WOL (at least for windows system, but I think for all systems) is really Wake up On Lan and Reboot the Operating System from Scratch (WOLROSS), how much do you really want all that to happen before you get a response to your keypress on the remote?

I'm not even sure why they implemented it in the SB2, considering how awfully it must perform.

Jim
2005-11-13, 22:16
I think I need to explain a bit better what I am suggesting.

Imagine a serious bugfix. Imagine now is 1999 and SB1 wasn't Y2K ready. the world would end anyway like they're saying but Slim would I imagine fix this and release a firmware upgreade.

Why don't Slim upgrade old SB1 firmware?

Because they have SB2/SB3 work to do - that pays the bills.
Because if they broke something it only means more work. Don't fix what isn't broken.
Because even if it were possible to do something if someone wants it that bad they will buy the current model (Slim need to make money). They had already bought the SB1 based on what it could do so you don't need to sell it to them.


Now the wake-on-lan issue is a strange issue. No doubt it's a simple fix and it can easily be applied to SB1. And nobody is going to buy a SB2/3 just for wake-on-lan (well there will always be 1). Luckily for users of the SB2 they are using the same firmware as "The New Squeezebox" (AKA SB3) otherwise I imagine they wouldn't be getting WOL.

But imagine Slim release new firmware for the SB1 officially....what can happen.


Introduce a bug
Someone screws up the upgrade, or it goes wrong

Both of these cost time/money for Slim hence the reason why they won't do it...even if it was changing 1 byte of code. They don't want to set a precedent either.

But now imagine as this is such a simple fix (I guess) and such a unimportant thing to most if someone somewhere acquired a unofficial file posted by someone who worked for someone.

Got me?

bcc
2005-11-13, 22:51
Wow guys. With my initial questions I was neither proposing some firmware reverse engineering effort nor expecting an expensive official support solution. There was an open bug report in the current database that appears to have been under investigation for quite some time; I was trying to get the status. I *was* considering even upgrading to a newer box if that is what it would take. I'm also still interested in knowing if the existing box is extensible enough to add such a feature without any firmware backport (such as through the trick I suggested, not reverse engineering).

Jim
2005-11-13, 23:07
...nobody is going to buy a SB2/3 just for wake-on-lan (well there will always be 1).


I *was* considering even upgrading to a newer box if that is what it would take.

Well, that's just given Slim a $$$ reason to NOT make the change (if they would have done - unofficially of course) versus if they make the change a bit of goodwill from a few SB1 users who want WOL who would never have upgraded just for this feature.

I say take the money Slim and let's all let this thread drop, as I couldn't care less about WOL :D

danco
2005-11-14, 00:25
On 13/11/05 at 21:01 -0500, Pat Farrell wrote
>That said, I've watched folks talk about wake-on-lan for ages, and
>I fail to see what about it is attractive. What are people
>hoping to accomplish? It always looked to me as a solution
>looking for a problem. Seems that getting a low power server
>and leaving it on all the time, like we do with routers, etc.
>makes the problem go away.

Yes, but I don't want to get a new server. My current computer
doesn't use a *lot* of power, but enough that I would rather the
machine is asleep unless I am going to use it fairly soon. I do keep
it on all the time, but asleep much of the time.

Wake-on-lan, and the Execute Script plugin let me wake and sleep my
computer from the SB, the two being in different rooms.
--
Daniel Cohen

danco
2005-11-14, 00:29
On 13/11/05 at 19:31 -0800, Michaelwagner wrote
>Personally, it seems to me like a feature looking for a problem.
>
>You can do 90% of the power savings by figuring out how to spin down
>the hard disk and getting a temperature controlled fan.
>
>Considering that the implementation of WOL (at least for windows
>system, but I think for all systems) is really Wake up On Lan and
>Reboot the Operating System from Scratch (WOLROSS), how much do you
>really want all that to happen before you get a response to your
>keypress on the remote?


Waking a system doesn't seem to me anything like rebooting.
Everything is back to where it was before sleep within a few seconds.
This is on a Mac.

>
>I'm not even sure why they implemented it in the SB2, considering how
>awfully it must perform.


--
Daniel Cohen

bcc
2005-11-14, 00:36
Well, that's just given Slim a $$$ reason to NOT make the change (if they would have done - unofficially of course) versus if they make the change a bit of goodwill from a few SB1 users who want WOL who would never have upgraded just for this feature.
You're twisting things again. Now I would probably *not* buy an upgrade box. Slim just earned negative goodwill based upon the unwillingness to support their hardware after just 1 year and the poor "community" response here. Also I somewhat resent being goaded to justify being interested in such a feature, but have come to expect such poor behavior from online anonymous "communities".

"The efforts of Slim Devices' Open Source community results in rapid development and a rich set of features, evolving in response to user feedback." says the web page...

kdf
2005-11-14, 01:04
On 13-Nov-05, at 11:36 PM, bcc wrote:

>
> Jim Wrote:
>> Well, that's just given Slim a $$$ reason to NOT make the change (if
>> they would have done - unofficially of course) versus if they make the
>> change a bit of goodwill from a few SB1 users who want WOL who would
>> never have upgraded just for this feature.
>> You're twisting things again. Now I would probably *not* buy an
>> upgrade
> box. Slim just earned negative goodwill based upon the unwillingness
> to
> support their hardware after just 1 year and the poor "community"
> response here. Also I somewhat resent being goaded to justify being
> interested in such a feature, but have come to expect such poor
> behavior from online anonymous "communities".
>
> "The efforts of Slim Devices' Open Source community results in rapid
> development and a rich set of features, evolving in response to user
> feedback." says the web page...
>
the hardware is VERY well supported, through the efforts of Triode and
upgraded graphics handling (as just ONE example). Even when it is a
problem with SliMP3 (1st gen SD hardware) every effort is made to
support upgrades where possible.
SlimServer is open source, but unfortunately the hardware isn't. SB1
had its limits, as all hardware does.

Please don't start twisting things yourself just to support some
argument that really doesn't serve anything toward your initial wishes.
The bug report is open. consider that a positive thing.

The wishes of SD would be to offer everything as open source, and so if
it can be possible, then it will come to pass. The fact that WOL is
offered with the SB2 firmware is a very clear sign that the desires of
users (even the ranting ones) are, in fact, considered. Despite claims
and conjecture, adding the feature is NOT necessarily easy. Please
avoid making yourselves look like idiots by suggesting that it is
simple when you really don't know. I don't know, but I do know how
often things can be FAR more complex than you expect. If it really was
easy, you'd see a lot more people stepping up to make it happen instead
of just claiming to know how but just not having enough time.

-kdf

Michaelwagner
2005-11-14, 07:05
Waking a system doesn't seem to me anything like rebooting. Everything is back to where it was before sleep within a few seconds. This is on a Mac.
I don't know how WOL is implemented on a Mac, but on a PC clone, the entire memory and CPU are powered down, the disk is powered down, almost all but a small amount of logic on the network card are powered down.

When the "magic packet" comes in, the network card, which has a wire to fire up the power supply, yanks the wire and the power supply comes up.

Then comes BIOS boot, then the operating system is started.

IF the operating system went away by hibernating, then the hibernation image is read in from disk. Otherwise, a full reboot occurs.

Even a hibernation image of a 512MB machine is not fast, and a full reboot slower still.

Meanwhile, the person at the SLIM remote has figured that the Slimserver has died, walked upstairs, and rebooted the server manually :-)

Like I said, I don't see the point.

Just spin down the hard disk and you're get 90% of the savings and 90% better response time when you do click the remote.

danco
2005-11-14, 07:54
On 14/11/05 at 06:05 -0800, Michaelwagner wrote
>danco Wrote:
>> Waking a system doesn't seem to me anything like rebooting. Everything
>> is back to where it was before sleep within a few seconds. This is on a
>> Mac.
>I don't know how WOL is implemented on a Mac, but on a PC clone, the
>entire memory and CPU are powered down, the disk is powered down,
>almost all but a small amount of logic on the network card are powered
>down.

I think there must be major differences here between Mac and Windows.
What about Linux?

There is nothing actually called "hibernate" on the Mac, I think
"sleep" on the Mac is somewhere between "sleep" and "hibernate" on
Windows, but I don't know Windows. Certainly Mac wake from sleep is
fast. I just tried putting my Mac to sleep in the middle of writing
this email, and it took less than ten seconds to wake up, with a
whole lot of other programs open. That's fast enough for Wake on LAN
to be useful, even if it may be, as you imply, not totally necessary.
--
Daniel Cohen

Roy Owen
2005-11-14, 08:58
>
> I think there must be major differences here between Mac and Windows.
> What about Linux?
>
> WOL is a hardware thing not necessarily an OS thing. If the machine is
powered down then it MUST reboot to load the OS. However, if the machine is
in a hibernation state then the hibernation file can be scraped off of the
HD and system state is restored. Caution is advised however if you powerdown
a machine, some machines (HP/Compaq for one) have a pwere off state in which
the PC is truely off and cannot be waked by magic packets.
--
Do meddle in the affairs of Dragons,
for you are crunchy and good with Tabasco.

dean
2005-11-14, 09:13
On Nov 14, 2005, at 6:54 AM, Daniel Cohen wrote:
> There is nothing actually called "hibernate" on the Mac, I think
> "sleep" on the Mac is somewhere between "sleep" and "hibernate" on
> Windows, but I don't know Windows. Certainly Mac wake from sleep is
> fast. I just tried putting my Mac to sleep in the middle of writing
> this email, and it took less than ten seconds to wake up, with a
> whole lot of other programs open. That's fast enough for Wake on
> LAN to be useful, even if it may be, as you imply, not totally
> necessary.
The new powerbooks also include something called "deep sleep" where
after you put your laptop to sleep it also writes the contents of
memory to disk. This is similar to hibernate on windows, but smarter.

If you wake it up before the battery runs down (takes a few days) or
is removed (say you are swapping batteries), then it wakes up very
quickly. (less than 5 seconds here!)

If the battery runs down or is removed, then it loads up the the
memory from disk, which may take 20 or 30 seconds, depending on how
much memory you have and how fast your computer is.

The beauty of this is that you don't have to think about it. Close
the lid, it goes to sleep. Do whatever you want. Open the lid, it
wakes up.

It just works.

I do know that on the Mac laptops WOL only works if the computer is
plugged in and I strongly suspect that it doesn't matter if it's in a
sleep or a deep sleep.

oreillymj
2005-11-14, 09:32
I don't know how WOL is implemented on a Mac, but on a PC clone, the entire memory and CPU are powered down, the disk is powered down, almost all but a small amount of logic on the network card are powered down.


Actually WOL from standby is very fast on a PC running Win XP. Typically if I leave my monitors on, the PC will be "alive" and usable before the LCD monitor screen comes on fully.

Standby state - S3 powers down everything except RAM and freezes the CPU.

What you seem to be refering to is hibernation - S4, which write the contents of RAM out to the HD and powers down almost completely. Resume time then becomes a function of how fast the HD can reload the data to RAM, how fragmented the HD is etc...

If you have an old PC that does not support ACPI, your standby/hibernate experience may be completely different.

See here http://www.microsoft.com/windows2000/techenthusiast/features/standby1127.asp



* APM offers power management only for those devices under BIOS control. Devices such as IEEE 1394 devices, which are not on the motherboard, cannot be power-managed. ACPI is not limited in this way.
* Enabling APM on some systems causes instability. In Windows 2000, Setup will automatically disable APM in systems with known problems.
* ACPI provides more device-specific power management. Also, ACPI can place your computer into five different power states. As your computer drops into deeper levels, it takes longer to resume from Standby. APM does not have this flexibility—Standby in APM is either on or off.
* ACPI power states include:
o S0 – Active, with all power on.
o S1 – Standby, with display and drives powered off, but power maintained for CPU, memory and fans.
o S2 – Standby, with CPU and cache power off.
o S3 – Standby, with only minimal power maintained to RAM for a fast startup.
(This is useful for desktops because it keeps your PC ready to use, but eliminates noise from fans and disk drives.)
o S4 – Hibernate with all power off and the image of your desktop saved to disk.
o S5 – Complete power off with all files closed and no image saved to disk.

Michaelwagner
2005-11-14, 19:08
I guess I don't have any systems that go into S2 or S3 state. Are these supported under W2K?

o S1 – Doesn't need WOL
o S2 – WOL is useful
o S3 – WOL is useful
o S4 – WOL is useful but would take half of forever.
o S5 – WOL would take forever.

The reason S4 state takes a long time is that the BIOS has to go through POST, then load the O/S boot loader. In most modern O/Ses, the bootloader checks a flag relatively early on to see if it was hibernating, and if it was, the hibernation image is read in, validity checked and then control is passed to it.

I don't know of any machines that have hibernation support right in the BIOS, but if there were such, they could speed things up a bit by not POSTing, which takes 15 seconds or more.

Let's say POST takes 15 seconds. Reading a 250MB (say) memory image at 12.5MB/s (not a bad average speed for a hard disk these days) would take 20 seconds. The memory image contains all the user storage, all the paging tables and other system tables, the video card storage, the state of all I/O hardware (except the LAN) that needs to be restored, so 250MB is probably a fair estimate there too. Add another 5 seconds for stuff I've forgotten, and I don't see how a machine can wake up from S4 state in much less than 40 seconds.

To me, that's a long time to wait in response to a remote control click in front of a squeezebox.

But that's me.

oreillymj
2005-11-15, 05:01
The page I took the info from was a Windows2000 page on the MS web site.

However when Win2k was released APM was far more common than ACPI. Also the power management option had to be chosen at install time. So if your motherboard mfg reeleased an ACPI bios at a later date after install, you have to do a complete re-install to pick the ACPI compatible kernel.

In device Manager, have a look at System Devices, check to see if an item called Microsoft ACPi-compliant system is present.

Tim Collins
2005-11-21, 11:04
I would like to see someone from Slim Devices step up and state whether this is a decision cause by an actual impassable technical barrier or if this is a resource decision based on this being the "no new firmware features" point in the SB1 lifecycle.

If this "WONTFIX" designation is to become the norm, how long until SB1 firmware is EOL for support, or is it already? I haven't found a policy anywhere on the site that spells this out and if I'm ever to spend any money in the future with Slim Devices, I would like to know how long Slim Devices plans to support and develop for that hardware platform from a firmware standpoint. Again, the concern here is not the server software piece, but the firmware itself.

There are numerous accolades granted to Slim Devices with regard to their customer service, even within this forum. I would like to see some action to back that up, even if it is just an honest, simple communication to set accurate expectations.

ChrisB
2005-11-21, 11:12
Strong words, Tim.

As I see it, WOL would be an enhancement to existing functionality. I
don't see many people in the industry working on enhancements for
products that no longer ship. It's not like you're asking for a bug to
be fixed. Perhaps the problem here is that Slimdevices have been too
open? Allowing all and sundry to file 'bugs', and expecting them to be
fixed? Ultimately, the SB1 stopped shipping a long time ago, and any
time spent on enhancements to this is time not spent on enhancing the
currently shipping model, which is what will drive sales.

Chris

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of Tim Collins
Sent: 21 November 2005 18:04
To: discuss (AT) lists (DOT) slimdevices.com
Subject: [slim] Re: wake-on lan for squeezebox 1


I would like to see someone from Slim Devices step up and state whether
this is a decision cause by an actual impassable technical barrier or
if this is a resource decision based on this being the "no new firmware
features" point in the SB1 lifecycle.

If this "WONTFIX" designation is to become the norm, how long until SB1
firmware is EOL for support, or is it already? I haven't found a policy
anywhere on the site that spells this out and if I'm ever to spend any
money in the future with Slim Devices, I would like to know how long
Slim Devices plans to support and develop for that hardware platform
from a firmware standpoint. Again, the concern here is not the server
software piece, but the firmware itself.

There are numerous accolades granted to Slim Devices with regard to
their customer service, even within this forum. I would like to see
some action to back that up, even if it is just an honest, simple
communication to set accurate expectations.


--
Tim Collins
------------------------------------------------------------------------
Tim Collins's Profile:
http://forums.slimdevices.com/member.php?userid=1215
View this thread: http://forums.slimdevices.com/showthread.php?t=18144

Michaelwagner
2005-11-21, 11:25
Ultimately, the SB1 stopped shipping a long time ago
March 2005 is a long time ago?

Jacob Potter
2005-11-21, 15:22
On 11/21/05, Tim Collins
<Tim.Collins.1yuzab (AT) no-mx (DOT) forums.slimdevices.com> wrote:
> I would like to know how long Slim Devices plans to support and
> develop for that hardware platform from a firmware standpoint.
> Again, the concern here is not the server software piece, but the
> firmware itself.

For reference, the last revision of the SLIMP3 firmware was 2.3,
released Feb. 2004. This was a few months after the Squeezebox1; it
fixed some network driver issues, but did not add any new features.

- Jacob

Marc Sherman
2005-11-22, 06:19
Jacob Potter wrote:
>
> For reference, the last revision of the SLIMP3 firmware was 2.3,
> released Feb. 2004. This was a few months after the Squeezebox1; it
> fixed some network driver issues, but did not add any new features.

I think it's pretty safe to say that _feature_ development for the
squeezebox 1 firmware was frozen the day they started working on the SB2
hardware (probably some time in fall of 2004, I'd guess). Support, ie:
bug fixing, is obviously still ongoing, as Jacob points out it still is
even for the venerable slimp3 hardware.

You really shouldn't ever buy hardware based on the promises (or in this
case, hints of possibilities) of future new features being added in a
firmware upgrade. If the hardware doesn't do what you want it to, don't
buy it until it does. If you were happy with the hardware when you
bought it, why aren't you happy still?

The fact that the zlimserver software is open source, and thus can still
be developed by third parties to add cool new features even if Slim
Devices falls into the Pacific in the next big quake, is rather
orthogonal to ongoing firmware feature development.

- Marc

Michaelwagner
2005-11-22, 06:48
even if Slim Devices falls into the Pacific in the next big quake
Ah, but we know that Sean backs up his music on the other side of the fault line ...

dean
2005-11-23, 10:38
On Nov 21, 2005, at 10:04 AM, Tim Collins wrote:
> I would like to see someone from Slim Devices step up and state
> whether
> this is a decision cause by an actual impassable technical barrier or
> if this is a resource decision based on this being the "no new
> firmware
> features" point in the SB1 lifecycle.

Here's the deal. Slim Devices is a small company and we need to be
careful about where we place our engineering resources.
The Squeezebox1 platform has reached its limits and adding any new
feature requires great care to make sure that nothing is broken.

We've made a hard decision to not add any new features to that
product in the future, but will issue critical bug fixes when necessary.

Tim Collins
2005-11-26, 09:33
Dean,
Thanks for your response.

seanadams
2005-11-26, 09:49
Addendum to Dean's message:

Yes, SLIMP3 and Squeezebox1 are out-of-production and while we continue to support them, the firmware is not in active development.

However, Squeezebox2, while also no longer produced, IS expected to continue getting new features for the forseeable future because it shares firmware with SB3.

Normally we prefer not to set expectations about our product roadmap but I will say this: the SB2/3 hardware and software has a lot more flexibility and room to grow than our previous architectures. Expect development efforts for this architecure to continue for a good while.