[T10] Disagree with power condition changes in 21-100

Bill Martin bill.martin at samsung.com
Thu Jul 29 16:18:17 PDT 2021

See inline.

Bill Martin

Chair INCITS T10
Co-Chair SNIA Technical Council

NVMe Board of Directors
SSD I/O Standards
Samsung Semiconductor, Inc.
Cell (408) 499-1839

From: t10-bounces at t10.org [mailto:t10-bounces at t10.org] On Behalf Of Gerry Houlder
Sent: Thursday, July 29, 2021 1:31 PM
To: T10 Reflector <t10 at t10.org>
Subject: Re: [T10] Disagree with power condition changes in 21-100

So Ralph, it sounds like you are agreeing that sending START STOP UNIT with power condition ACTIVE, IDLE, or STANDBY does disable/ stop/ suspend the power condition timers and they stay that way until another START STOP UNIT command lets them return to regular operation. That means that other commands received may transition the target to active power condition and it stays there until the START STOP UNIT occurs (or power cycle). As long as you agree that this is the specified behavior then the choice of whether the timers are suspended/ stopped/ disabled is just semantics.

Bill started this off by not liking the fact that the timers stay "disabled/ suspended/ stopped" and are not reactivated by a subsequent command. That is the point we need to resolve.
[<wrm>] I did not have a preference here, just asking about the conflict between SPC and SBC. I believe that Ralph has come to agree with your position at the T10 meeting and now it is a matter of documenting that interpretation.

Ralph, I don't think that makeing changes to all of the power conditions state machines and descriptive clauses (there are state machines and descriptive clauses in SPL, SPC, and SBC) that would have to be updated accordingly. I think the best approach is to leave them all as is and add an Annex to SBC-5 That give guidance to hosts about the several intended use methods for the available power condition tools specified by the START STOP UNIT command and the Power Conditions mode page control the power conditions in the presence of commands and background tasks.
[<wrm>] I would STRONGLY disagree with burying this in an annex. We should have a concise definition in the body of the normative specification that gives one and only one interpretation of this operation. As such, I support the direction that Ralph is taking on this.
From: t10-bounces at t10.org<mailto:t10-bounces at t10.org> <t10-bounces at t10.org<mailto:t10-bounces at t10.org>> on behalf of Ralph Weber <Ralph.Weber at wdc.com<mailto:Ralph.Weber at wdc.com>>
Sent: Thursday, July 29, 2021 11:10 AM
To: T10 Reflector <t10 at t10.org<mailto:t10 at t10.org>>
Subject: Re: [T10] Disagree with power condition changes in 21-100

This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.

A private correspondent has reminded yours truly that SCSI-2 defined the START STOP UNIT command.

What 91-014r6 (http://www.t10.org/ftp/x3t9.2/document.91/91-014r6.txt<https://urldefense.com/v3/__http:/secure-web.cisco.com/1UfeHQ-a3r_hwFrIX4v7P1ji0iNUfxrLADJR06IaFdZzsl_HP8snLsJEmRX9XLqX9tFL8a1zzhhHR-lYto8GVrDrn19zHpfBgTpWdOwcxyetkWYLJXj0W0FVMdUIRceo28If_LFp2QHcsbwPL2qsvWjpnbFMWcLxw3tpRlJ-QUU_JcwSaTxEKgRokpW5dNJnltChfgm2GXtWsalJPIT0_hPxTMW2ZptzXrLrL47VMhKEkvCd6EJ2tJ0FHUh38Qkn3Taq7iZt0gL-ePf2hzmnN8DbHXglR-CWMOsjj2rPocec92QvPP-PZ9uvsEWAgacxz7fZtcnt_rGJmuJYav28_mbfcQWEx8Fy_mBejpD_HlC0PUuQJ3tKPv9ougxBg6Mne5N3iHnnQsOWEVkrDl2hnDNDygz9xB8PR4YrInrguZ07gAs6oM7UvBegGYBng39m5/http*3A*2F*2Fwww.t10.org*2Fftp*2Fx3t9.2*2Fdocument.91*2F91-014r6.txt__;JSUlJSUlJQ!!EwVzqGoTKBqv-0DWAJBm!AR2qt7wCwuKq9YgtuRCDO94pAl7UklnBwJTV6MYJaj4RONpthSpQ1e1leLP5Us7nhxkm$>) added was the POWER CONDITION (nee CONDITIONS) field along with all the codepoints shown in SBC-5. All the processing requirements under debate in this thread were also defined in 91-014r6 in very much the form that they have today.

All the best, .Ralph

From: t10-bounces at t10.org<mailto:t10-bounces at t10.org> <t10-bounces at t10.org<mailto:t10-bounces at t10.org>> On Behalf Of Ralph Weber
Sent: Thursday, July 29, 2021 6:58 AM
To: T10 Reflector <t10 at t10.org<mailto:t10 at t10.org>>
Subject: Re: [T10] Disagree with power condition changes in 21-100

First, the POWER CONDITIONS field was not added to the START STOP UNIT command as the result of some random proposal that postdated the command's original creation. Both the command and the field were added by 91-014r6 (http://www.t10.org/ftp/x3t9.2/document.91/91-014r6.txt<https://urldefense.com/v3/__http:/secure-web.cisco.com/1UfeHQ-a3r_hwFrIX4v7P1ji0iNUfxrLADJR06IaFdZzsl_HP8snLsJEmRX9XLqX9tFL8a1zzhhHR-lYto8GVrDrn19zHpfBgTpWdOwcxyetkWYLJXj0W0FVMdUIRceo28If_LFp2QHcsbwPL2qsvWjpnbFMWcLxw3tpRlJ-QUU_JcwSaTxEKgRokpW5dNJnltChfgm2GXtWsalJPIT0_hPxTMW2ZptzXrLrL47VMhKEkvCd6EJ2tJ0FHUh38Qkn3Taq7iZt0gL-ePf2hzmnN8DbHXglR-CWMOsjj2rPocec92QvPP-PZ9uvsEWAgacxz7fZtcnt_rGJmuJYav28_mbfcQWEx8Fy_mBejpD_HlC0PUuQJ3tKPv9ougxBg6Mne5N3iHnnQsOWEVkrDl2hnDNDygz9xB8PR4YrInrguZ07gAs6oM7UvBegGYBng39m5/http*3A*2F*2Fwww.t10.org*2Fftp*2Fx3t9.2*2Fdocument.91*2F91-014r6.txt__;JSUlJSUlJQ!!EwVzqGoTKBqv-0DWAJBm!AR2qt7wCwuKq9YgtuRCDO94pAl7UklnBwJTV6MYJaj4RONpthSpQ1e1leLP5Us7nhxkm$>) as one of the first enhancements made during the transition from SCSI-2 to SCSI-3.

Furthermore, 91-014r6 includes the requirement that putting the device server in ACTIVE, IDLE, or STANDBY with a START STOP UNIT command automatically prevents the power condition timers from expiring until something is changed by another START STOP UNIT command. Clearly, there can be no questions about whether the behavior was an accidental addition. It's a Day One thing, clear and simple.

Therefore, 21-100 adds a paragraph to the SBC-5 model clause 4.20.1 (START STOP UNIT and power conditions overview) with the goal of leaving future readers an unambiguous description the model.

There is, however, a one-word fly in the ointment, and that one word is "suspend".

In keeping with the style used in the 1990's, 91-014r6 says

"If the Start/Stop Command is issued with the Power Conditions field set to 1, 2, 3, ... the logical unit shall ... suspend any Power Condition timers (see Table 1) that are active on receipt of the Start/Stop Command until another Start/Stop Command is received which returns control of the power condition to the logical unit or a hard reset occurs."

Present at the beginning of SCSI-3, the word "suspend" remained in SBC for the better part of a decade.

The careful consideration (not) given to "suspend" by a 2002 CAP when 02-464 brought the word to the group's attention is easy to imagine.

"What does 'suspend' mean? Are we hanging the timers for the ceiling by threads?"

"Acrobat says that the word 'disabled' appears 32 times in SBC-2 r08. That sounds about right!"


Did anybody question the fact that any realistic English Thesaurus identifies "disable" as an antonym for "enable", and that making timers "enabled" is what the mode page controls? Of course not!

Nearly everybody in the room had a satisfactory implementation upon which the tiny change would have no effect. The agony would visit T10 only another decade later, when new engineers tried to read sense into the spec.

Into this malaise strides 21-100. Neither "suspend" nor "disable" fits the situation at hand. SPC-6 uses "stop" several times to describe the device server making it impossible for a timer to expire. Doubtless noting this usage, Kevin Marks suggested "stop" as a wording correction during the July CAP debate.

In hopes of preventing a future Acrobat search from setting fire to all the best intentions, 21-100 adds a mini-model for power condition timers in which terms such as "stop" are named and given a detailed meaning, while also changing the SBC-5 "disabled" to "stopped as described in SPC-6".

Since 21-100r0 has the "r0 curse", every Las Vegas bookie worth his salt has set the odds strongly in favor of some additional improvements being made in the weeks to come.

All the best,


From: t10-bounces at t10.org<mailto:t10-bounces at t10.org> <t10-bounces at t10.org<mailto:t10-bounces at t10.org>> On Behalf Of Gerry Houlder
Sent: Tuesday, July 27, 2021 3:02 PM
To: T10 Reflector <t10 at t10.org<mailto:t10 at t10.org>>
Subject: [T10] Disagree with power condition changes in 21-100

The proposal starts off by asserting that proposal 02-464r3 "unintentionally" veered away from the principle of maximum flexibility. I disagree with that. Those of us that participate in T10 and other standards group know that proposals are discussed and intentionally approved. This proposal was not an exception to that rule.

02-464r3 (i.e, the 2002 proposal) retains all of the flexibility of power control but adds new features to control the different power control philosophies. Up until that proposal the different power control philosophies were at the whim of vendor specific behavior and this proposal added the features to specifically allow several different power management philosophies and methods to change from one philosophy to another. Let me describe the ways.

First, there is the timer managed power control method which uses a mode page that sets initializing values for the internal timers to automatically transition to lower power levels if the device is not processing commands. In addition there are enable bits to allow the timers to be started and become expired. This is OK for hosts that want to give control of when to go into lower power conditions to the target device. However, this comes with the problem that targets can transition to low power conditions at unexpected times. When this happens, the target device takes longer to process the next incoming command than if the target device had stayed in its active power condition. Hosts wanted a way to override that.

Second, a proposal responded to the hosts desires by adding the power condition field to the START STOP UNIT command. This allows hosts to explicitly force the target device into specific power conditions (the ACTIVE, IDLE, and STANDBY cases). In this mode of operation, the host explicitly puts the target device into a specific lower power condition and it stays there until a command is received. After the command is completed, the target stays in active power condition in order to eliminate the performance hit of having to transition from a lower power condition to the active power condition to process future commands. This is the "performance is more important than lower power" mode. When the host is done using this target, it can send another IDLE or STANDBY power condition request to get back to a lower power state.

Third, what if a host wants to get from "performance more important than lower power" to timer managed power condition mode. Sending a START STOP UNIT command with power condition field set to LU_CONTROL will do that.

Fourth, the group realized that we wouldn't have needed the LU_CONTROL option if there was a way to force the target device to a particular low power condition without disabling the timers. The FORCE_IDLE_0 and FORCE_STANDBY_0 options of the START STOP UNIT command were devised to do this. Now the host doesn't have to use LU_CONTROL to get back to timer controlled low power mode. This is subject to unexpected transitions to lower power states again, so this is "performance is less important than lower power" mode.

A reader in this century (we need to remember that some of the power management stuff I just went through was developed in the last century) might ask "why wouldn't we just require the host to disable and enable the timers using MODE SELECT commands? The prevailing opinion on use of MODE SENSE and MODE SELECT commands is that they should be used for setting the configuration of the target device at installation time and not used for frequently changing a configuration like power management during normal operation. That is why the host community wanted to use START STOP command to control the two major configurations (performance more important vs. performance less important).

These are all the reasons behind why "disabled" should not be replaced by stopped. If disabled is replaced by stopped, then the function of the IDLE and STANDBY power condition options would be neutered to have the same effect as the FORCE_IDLE_0 and FORCE_STANDBY_0 power condition options and the LU_CONTROL option would become moot. It would eliminate options that have been defined for the last 19 years. If we want to enhance the power condition model, it should be enhanced by more clearly explaining how to use the existing options in a coherent way. A coherent model was hard to explain in the past because the mode page timers description is in SPC and the START STOP UNIT command description is in SBC, so the SPC power condition description didn't want to include the START STOP UNIT behavior (as other than a reference to "commands in other command sets") because it is command set specific and not in SPC. Perhaps we need to leave SPC as is and enhance the power condition model in SBC (clause 4.20).

I recommend everyone compare 02-464r3 with current wording. There have been several style changes over the years (giving ample opportunity to revisit the features) but the changes have been editorial except for the addition of multiple idle and standby levels, which were accommodated by adding another field to the START STOP UNIT command.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.t10.org/pipermail/t10/attachments/20210729/78dba7e4/attachment.html>

More information about the T10 mailing list