Standby aka Snooze mode

C

Cancunia

Member
Hope you don't mind, thought it best to start another post, following on from my questions about LAN & USB in standby, this time specifically around standby mode or 'snooze' as coined by Ezra the other day, slumber comes to mind too, but I'm not precious about the name tbh.

Why do I think this mode is useful? Well, when compared with fully awake, it uses approx 25% less power (10W as opposed to 12-15W) and the CPU runs at about 50% less (4% as opposed to 8-10%), but you still get remote access. Admittedly, the savings are minimal, but any less stress is useful and perhaps it could be extended in the future to spin down the disk too.

The box can be put into standby by adding a wake up, plus 2 shutdowns via the RS Scheduler, Webif sees the box as 'standby', Redring shows 'half awake' and without Redring the front panel appears to be the same as Idle. My question is, can this be achieved in a more elegant fashion than via the slightly clunky method described here?

Thanks
 
I think the state you are getting the Humax into is just the normal' Half Awake' and I guess the power savings are achieved by having the HDMI / video output processing off. The suggested 'Snooze / Slumber" state would hopefully spin down the HDD except for the brief times it is accessed over the LAN, if this is possible. I agree that it would be a step forward to be able to put the Humax in the Half Awake state with a single command
 
Seems that the native FTP server is not running in Half Awake, not yet tried the BetaFTPd. If the box goes into half awake just before recording or waiting for OTA updates, presumably there's a script somewhere that does this.
 
Cancunia said:
If the box goes into half awake just before recording or waiting for OTA updates, presumably there's a script somewhere that does this.
Click to expand...

There must be a wake up from standby in half awake mode function, within humaxtv (the main Humax Linux program), however as a general rule the Custom Firmware does not alter or have access to this code so it may not be something that the CF can do, in the normal way
 
As far as I understand it, the RTC is programmed during each controlled shutdown to say when it next has to wake up. The question is, how does it know what to do when the alarm goes off - is there a status flag in memory, or is it a code sent from the RTC?
 
IIRC There's an extra status code associated with the timer when it's set.
 
SO we probably could force a reboot in half awake mode, followed by an ir (channel) 200 and a disable_tsr. The only problem with disable_tar is that some users are reporting that it doesn't spin down the HDD
 
Ezra Pound said:
SO we probably could force a reboot in half awake mode, followed by an ir (channel) 200 and a disable_tsr. The only problem with disable_tar is that some users are reporting that it doesn't spin down the HDD
Click to expand...
Unfortunately, disable_tsr does not spin the disk down on my HDR, the feature is active as I can no longer pause / rewind. It may well be that log files or other reads / writes prevent it. Maybe an alternative would be a redirect to Null or a USB disk, depends of course on what's being written or read. For now, I'd be happy with a more graceful means to get into half awake mode.
 
Have you tried running hdparm to enable drive spin down?

Code: 
humax# hdparm -S 60 /dev/sda

should set the spin-down to 5 minutes.

Seems to work here, also forcing the drive to immediate sleep works..

Code: 
humax# ir TWO ZERO ZERO OK
TWO (0x4)
ZERO (0xc)
ZERO (0xc)
OK (0x13)
 
humax# status
Watching 200: BBC Red Button
 
humax# hdparm -C /dev/sda

/dev/sda:
 drive state is:  active/idle
humax# hdparm -y /dev/sda

/dev/sda:
 issuing standby command
humax# hdparm -C /dev/sda

/dev/sda:
 drive state is:  standby
 
Thanks for the pointer af123. Hopefully I'll find my way around a bit in the near future, at the moment my understanding is little better than being in the dark without a torch with some distant memories from the 90's Unix days to help me around.
Ok. Disparm did not seem to have an effect when issued as a command during half awake, although the responses from the -y command are as expected, the disk state from -C did not change, if anything, the disk temp went up... Putting the HDR into fully awake and re-issung the -y command showed the disk state changed to standby. However, having checked a few minutes later the disk is again active/idle so perhaps there are a regular read /writes that meaning the standby state is very short. I'll do some more testing on this.
 
Unfortunately, hdparm does not keep the disk spun down even in half awake. Something is regularly accessing the disk every 30 seconds or so from what I can tell. Just in case that's Sysmon, I've removed it and will check via hdparm status over the next couple of days. Are there are any other packages that can be tuned to minimise their disk usage?
 
sysmon will definitely access the disk each minute to read the temperature - probably causes a spin-up.
I would reboot to maintenance mode, at which point nothing will be running and see if stays spun down, then start each service in turn (by running the startup script under /mod/etc/init.d/) and re-test.
 
I'm away for a couple of days (part of the reason for wanting Half Awake), but will take a look on Friday.

Thanks for the pointer.
 
Booting into maintenance mode and spinning the disk down does leave it idle, but seems that just about anything including 'ps -A' or 'cd /mod/etc/init.d' will spin the disk up. Looks like it's going to be a challenge to get the disk to stay in standby.
Anyone any thoughts on how to get into half awake mode easily? I'll settle for that for the time being.
 
Perhaps setting a spindown timeout would help but you would still have the problem of how to keep it spun down.

Code: 
hdparm -S <n> /dev/sda

where <n> is in units of 5 seconds (0 disables the spindown timeout)
 
I have the timeout set to 5 mins, any less would probably result in more power & wear than leaving it spinning. Unless there's a way to make the system run with much lower disk usage it's probably a non starter. Can't see any point in tracking down disk usage by package when the system itself is apparently prone to disk access.
 
You must log in or register to reply here.
Back
Top