Things I don't like about proposal 08-126

Knight, Frederick Frederick.Knight at netapp.com
Mon Mar 24 13:06:13 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
I absolutely agree with point (c).
Standby and Idle take no special action to enter (timer based), and they
take no special action to exit (just send a command).  Those power modes
(aside from their timing) can be pretty much transparent to the host.
Sleep however takes special action to exit, and therefore should take
special action to enter.  There is nothing transparent about sleep; the
host must know it needs to take special action to issue the WAKEUP,
therefore the host must know when the device is in that state.	Since
the host can not query to findout if the device is in sleep mode, the
only other option is to have the host be the one that puts the device
into that state.
Automatic (timer based) transition to sleep is bad.
	Fred Knight
	NetApp
-----Original Message-----
From: Gerry.Houlder at seagate.com [mailto:Gerry.Houlder at seagate.com] 
Sent: Monday, March 24, 2008 3:00 PM
To: t10 at t10.org
Subject: Things I don't like about proposal 08-126
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Proposal 08-126 will reintroduce the SLEEP state to SCSI. I am opposed
to this for several reasons:
(a) Investigation of my company's SATA implementation (which includes
both STANDBY and SLEEP states) shows that SLEEP state has the same power
savings as STANDBY. Since SLEEP provides no power savings over STANDBY
there is no advantage for it. I recommend other companies look into what
they might do differently for SLEEP versus STANDBY so I can be sure my
analysis is typical of the industry.
(b) SLEEP is a lot more trouble for the initiator in terms of what it
has to do to wake up a target and initialize it to accept commands. If
it provides no power savings, the extra trouble is not worth it.
(c) Even if I thought SLEEP was useful, using a timer expiration to
invoke SLEEP is a bad thing. If a target goes into SLEEP mode without
the initiator's knowledge, the initiator will probably try to send it a
command and get unexpected timeout. The initiator will likely assume (by
today's
interpretation) the target has died and will flag it as such. SATA gets
around this issue by only allowing SLEEP to be entered by express
command from the initiator. In this way the initiator should know that
the target is put to SLEEP and should know that the WAKEUP procedure is
needed before sending a command. This suggests that even interfaces that
define and use SLEEP do not want this state to be entered by targets on
their own accord (e.g., timer expiration).
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org



More information about the T10 mailing list