Standby timers not setting correctly.

[CodingGhost]

Im trying to set the standby timer value to a few hours on all my HDDs. some are EPC capable, some only APM.
Im doing this with something like that:
sudo openSeaChest_PowerControl --standby 7200000 -d all
the resulting standby_Z value seems to be capped by int max:
Standby Z *65535 9000 9000 125 Y Y

this would be only less than 2 hours as max value.

some other values behave strange too, for example setting it to 1900000 results in a value of 18000.

Is this a bug in openSeaChest, or in the HD firmware or something else?

[vonericsen]

Hi @CodingGhost,

I don't see a limitation of 2 hours anywhere in the standards or within the code as we track everything within uint32s.
I walked through the debugger once to see if there was a bug translating any of it, but I did not find one.

I'll keep debugging this to see if I can figure out why this might report like this since that is oddly specific to a 16bit maximum value, which definitely seems more like a bug than anything else.

One thing that we need to work on clearing up is the command line has expected milliseconds forever, but internally we convert that to 100 millisecond units (division by 100) to convert it to the drive value that is expected.
EPC wants things this way and that is how we report it outwards (hence the confusion since it differs from command line units which don't require the 100 milliseconds).

On old ATA disks, the standby timer is also very strange in the conversion and requires some translation to get it as close as requested.
We followed SAT for translation but a nice even 2hours converts nicely to F4h which shouldn't truncate anything or round in a weird way.
This is a snapshot of the values allowed for the legacy ATA timer to show how odd it can be to set:

Can you share the verbose output so I can see the raw values from this drive? This will help me figure out where the issue is.

openSeaChest_PowerControl --standby 7200000 -d <handle> -v4 | tee setStandby.txt

openSeaChest_PowerControl --showEPCSettings -d <handle> -v4 | tee epcSettings.txt

[CodingGhost]

thanks for taking the time and looking at it. here are the results:

epcSettings.txt
setStandby.txt
setStandbyAPM.txt

I also added another command output where I try to set a value of 240000 to a drive that only supports APM, as this behaves strange too(small values <60s seem to work ok, but bigger values seem to have no effect. My drive spins down every 60s and I dont know how to change it currently)
btw, is there any way I can completely reset a drives firmware settings to a known good state?

[vonericsen]

@CodingGhost,

Thanks for the logs!

The conversion to F4h is going as I would expect it to work and the command format to the drive looks correct.
If you plug it into the table earlier, you see ((F4h - 240) * 30 which results in 2 hours or 240 minutes which is doing what it is asked to do.

When I look at the raw EPC bytes, the drive is reporting that 65535 value, but I do not know why.
If you convert that value (65535 * 100 to get milliseconds) to hours it is 1.82 hours.

The maximum value is also reported in the EPC settings for the drive, but that also matches the ATA spec's maximum of 429_496_729_500 milliseconds.

I will see if I can find someone in the firmware team who can provide a better answer on this, but with the ATA spec's

Note - Times are approximate

and whatever the conversion is being done inside the firmware is rounding it to this value this is probably technically correct per the specification, even if it's not exactly what a user would expect. The ATA spec has a lot of carve outs like this from years and years of history and what drives could or could not do properly/accurately.

The oldest document I have come across on how to use this command to control the standby timer is from a Conner Peripherals manual dated October 1989. The first ATA specification was published in the early 90's so it existed before it was standardized (and this drive should still work with these tools if the OS can spin it up and identify it).

You could try setting something above 2 hours, like 5 hours, to see if that changes the results in the EPC log at all which should tell us if it is a truncation issue or a conversion issue when it receives this command.

In the EPC description it does say the drive should accept changes to the legacy timer value (which is what the --standby option is doing) to change the "current" EPC timer value for standby_z. The drive does seem to be doing this, although not quite as accurately as expected.

For APM that has a different set of interactions with this legacy timer (and it is incompatible with EPC. You can enable one or the other, but not both).

This is what the spec says about APM and the standby timer

This is saying is:
If the standby timer expires -> go to standby
AND
If the APM algorithm expires -> go to standby

So whichever one of these counts down first is determining when to spin down.

For this case you also need to change the APM value to something else.

If you want the standby timer you are setting to determine when to spin down then you should set a higher value for APM. This means APM will take longer to count down and enter standby than the standby timer.

I would expect if you set APM to 80h (128 in decimal) then this will work how you expect it to. In this mode the APM will never trigger the standby itself and only handle when to enter idle power states.

ATA Feature set interactions are a bit of a maze to navigate sometimes. I've been meaning to add a page to our Wiki on all the power settings out there since it is a bit confusing.

btw, is there any way I can completely reset a drives firmware settings to a known good state?

When it comes to these power settings, all you need is a power cycle to restore back to defaults. Neither the legacy standby timer or APM are saved across power cycles. This gets people all the time....

EPC on the other hand does save across power cycles (if the column for S a.k.a. Savable is set to Y).

For other features it can be a bit more complicated on ATA drives to restore to defaults. Some, like EPC, have a column or some way to identify the default behavior, but not all of them.
We can look into some kind of "restore all things to default" option, but it will take some time before we can get to it.

[CodingGhost]

thanks a lot for this explanation. This cleared up many false beliefs of how the APM system works!
setting it to 128 is indeed what I wanted.

I have two other logs for you, where I directly set the standby_z timers with a longer interval. This seems to work, which leads me to believe it is a conversion issue, although you said it is converted correctly?

epcSettingsLong_z.txt
epcStandbyLong_z.txt

[vonericsen]

I'm glad to help explain it! I know it is a bit confusing to read through how the spec writes about these.

This seems to work, which leads me to believe it is a conversion issue, although you said it is converted correctly?

I am working on finding someone within our firmware teams to help validate if this is really the expected value using the legacy standby timer command or a bug in conversion.

Until I know more from them, correctly is not the right word to use here to describe the conversion. I would go with As allowed per ATA standard.
Since the standard includes the Times are approximate you can end up with some conversions like this that are allowed since approximate is how the spec defines the values that get set.

As another note, we have been discussing how we could implement a JSON configuration file to set EPC, APM, etc in our tools.
This is a case that I have been thinking about a lot....how could that file indicate precedence or when to not throw errors if all drives it is applied to do not support EPC?
Is there a way to say "EPC first, fallback to legacy timers otherwise" that is clear and easy to indicate that we could use in software to handle this kind of thing since I know lots of people mix and match drives all the time.
We don't have a timeline for this yet, but I think this is a good case to consider....any input you have on this would be great.