Date: Tue, 25 Mar 2008 21:00:31 -0700
Subject: Re: Things I don't like about proposal 08-126
From: Mark Overby <MOverby@nvidia.com>
To: <Kevin_Marks@Dell.com>, <George.Penokie@lsi.com>,
Jim Hatfield <James.C.Hatfield@seagate.com>, <t10@t10.org>
X-Message-Number: 8647
Formatted message: HTML-formatted message
It appears I misunderstood.
On 3/25/08 7:32 PM, "Kevin_Marks@Dell.com" <Kevin_Marks@Dell.com> wrote:
> It was my understanding that in Rob's proposal, the port is also
> inactive, only looking for a hard reset event to trigger recovery.
>
> Kevin
>
>
> -----Original Message-----
> From: owner-t10@t10.org [mailto:owner-t10@t10.org] On Behalf Of Penokie,
> George
> Sent: Tuesday, March 25, 2008 7:41 AM
> To: Mark Overby; James.C.Hatfield@seagate.com; t10@t10.org
> Subject: RE: Things I don't like about proposal 08-126
>
> * From the T10 Reflector (t10@t10.org), posted by:
> * "Penokie, George" <George.Penokie@lsi.com>
> *
> Mark,
>
> Well, not quite. To get a response to a command, any command, the device
> has to come out of sleep which would delay the response to that command
> and possibly cause a command timeout. Remember it's the device that is
> in sleep mode not the port so all ports would have the delay.
>
>
> Bye for now,
> George Penokie
>
> LSI Corporation
> 3033 41st St. NW
> Suite 100
> Rochester, MN 55901
>
> 507-328-9017
> george.penokie@lsi.com
>
>
> -----Original Message-----
> From: owner-t10@t10.org [mailto:owner-t10@t10.org] On Behalf Of Mark
> Overby
> Sent: Monday, March 24, 2008 6:38 PM
> To: James.C.Hatfield@seagate.com; t10@t10.org
> Subject: Re: Things I don't like about proposal 08-126
>
> * From the T10 Reflector (t10@t10.org), posted by:
> * Mark Overby <MOverby@nvidia.com>
> *
> However, in a real SCSI world you'd get an ASC(Q) to the other initiator
> (at least that's the way I understood the proposal) indicating that an
> initializing command is required.
>
>
> On 3/24/08 1:35 PM, "James.C.Hatfield@seagate.com"
> <James.C.Hatfield@seagate.com> wrote:
>
>> > * From the T10 Reflector (t10@t10.org), posted by:
>> > * James.C.Hatfield@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@seagate.com
>> > s-mail: 389 Disc Drive; Longmont, CO 80503 USA
>> > voice: 720-684-2120
>> > fax....: 720-684-2711
>> > ==========================================
>> >
>> >
>> >
>> > Gerry.Houlder@sea
>> > gate.com
>> > Sent by:
> To
>> > owner-t10@t10.org t10@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@t10.org), posted by:
>> > * Gerry.Houlder@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@t10.org
>> >
>> >
>> > *
>> > * For T10 Reflector information, send a message with
>> > * 'info t10' (no quotes) in the message body to majordomo@t10.org
>
>
> ------------------------------------------------------------------------
> -----------
> This email message is for the sole use of the intended recipient(s) and
> may contain confidential information. Any unauthorized review, use,
> disclosure or distribution is prohibited. If you are not the intended
> recipient, please contact the sender by reply email and destroy all
> copies of the original message.
> ------------------------------------------------------------------------
> -----------
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo@t10.org
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo@t10.org
>