Things I don't like about proposal 08-126

James.C.Hatfield at seagate.com James.C.Hatfield at seagate.com
Mon Mar 24 13:35:35 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* James.C.Hatfield at seagate.com
*
For dual ported devices: Another reason for not supporting SLEEP is that
one initiator could put it to sleep
without the knowledge of another.
Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
Seagate Technology LLC
   e-mail:  James.C.Hatfield at seagate.com
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:  720-684-2120
   fax....:  720-684-2711
==========================================
	     Gerry.Houlder at sea						   
	     gate.com							   
	     Sent by:							To 
	     owner-t10 at t10.org	       t10 at t10.org			   
	     (952) 402-2869						cc 
								   Subject 
	     03/24/2008 12:59	       Things I don't like about proposal  
	     PM 		       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