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

Gerry Houlder gerry.houlder at seagate.com
Tue Jul 27 13:02:17 PDT 2021

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/20210727/dbf9517c/attachment.html>

More information about the T10 mailing list