hdparm, changing the hard-disk spindown (sleep time)

[Richard Hughes]

On Tue, 2005-08-23 at 22:14 +0200, Danny Kukawka wrote:
> On Tuesday 23 August 2005 20:06, Richard Hughes wrote:
> > This is a very rough and ready patch.
> >
> > To finally drive a nail in the coffin for the bodge that is PowerManager
> > dbus daemon, this is a quick patch to add a:
> >
> > org.freedesktop.Hal.Device.SystemPowerManagement.SetSpindown (seconds)
> >
> > method to all hard disks. This lets us abstract the detail of hdparm
> > (and its weird ID mapping) and lets any application use the spindown
> > sleep method.
> >
> > I understand that SetLowPowerMode may do this sort of thing there, but
> > it made sense to use HAL to call a HAL method, if you see what I mean.
> >
> > Plus it gives other programs the fine-grained spindown control.
> >
> > What do ppl think? Is there an easy (cross-distro) way of calling
> > hdparm?
> 
> I'm not sure if it is a good idea to add this to HAL. It's not really needed 
> for powermanagement. Harddisks have a really intelligent powermanagment. You 
> lose with such solution more than you win. 
> 
> Here the power consumption data for a notebook harddisk (ide/sata):
> Startup (peak, max.)		5.5W 	NC	
> Seek				2.3W	2.7W	
> Read (avg.)			2.0W	2.3W	
> Write (avg.)			2.0W	2.3W	
> Active idle (avg.)		1.1W	1.2W	
> Low power idle (avg.)	0.85W	0.9W	
> Standby (avg.)			0.2W	0.25W	
> Sleep				0.1W	NC
> 
> * A disk on Low Power idle need less than 1 Watt per hour for a normal battery 
> with 50000mWh you can let run the harddisk 50 hours. The harddisk is not the 
> point to save power. 

I thought the difference would be greater than this.

> You maybe win on a battery fuel maybe 1-3 minutes (or 
> something like this). If you would like to save power it make, if any, more 
> sense to use the advanced powermanagement features of a disk.

Can you turn this on with hdparm? Or is it on by default?

> * If you not read/write from/to the harddisk the disk regulate the disk down, 
> but never shut down the device. The reason is easy: you lost more power with 
> each startup than let the harddisk online somewhere between 'Active idle' and 
> 'Low power idle' (depends on the model/manufacturer/version maybe also 
> standby). 

Sure, I see what you are saying.

> * Other reason to let do this the intelligent internal powermanagement of the 
> disk is: the time needed to reactivate the device. You lose more performance 
> than you lose power between 'Active idle' and 'Low power idle'.

I know, my spin-up is about a second.

> * If you use a journaling file system: you normally need to flush 
> periodically. This could run in a race between shut down device and restart 
> device by system to flush. This means more power consumption as if you change 
> nothing.

Will laptop_mode kernel magic help here?

> * Different of actual HDDs react on the usage of the disk and adapt this to 
> the own powermanagement. If you engage to this process you can reduce the 
> lifetime of the disc (e.g. trough unneed increase Load_Cycle_Count, can also 
> be a effect in races as above) and again: lose more power than you save.
> 
> * And at least: the manufacturer of harddisks for notebooks know what they do 
> and they optimized the devices. ;)

This is a good point.

> We had this in the past also in powersave, but we removed this because of the 
> points above and trouble with some decives. And with upcomming SATA drives 
> this should not work IMO (I think hdparm work only with IDE, or?).

Just IDE I think.

> > Plus it gives other programs the fine-grained spindown control.
> Problem: What if different applications with different settings try to set 
> their own settings? Not a good concept, or?
> 
> If you need more info our specialist for powermanagement and harddisks if back 
> next week from holidays.

No I get the idea :-)

> What you think?

I agree with your reasoning, if your data is correct. I think I'll
remove the hard-disk spindown bits in g-p-m now (and because davidz said
they didn't belong there...)

Thanks for the detailed mail, appreciated.

Richard.