[Freedos-user] UIDE vs drive power management spin down timers
Jack, [others: this is a bit long/technical, the summary is that it is both easy and safe to use shallow drive power management.] The problem is WHERE does UIDE or any other driver wait for a sleeping, i.e. stand-by hard disk to awaken again?? The ATA specs do not make this clear. Can UIDE simply issue a drive-select command to the disk and await ready for it? Or, does UIDE actually have to issue a seek or read, and then retry that command when first it fails?? As far as I remember, DOS always considers retrying the read. I seem to remember that MS DOS would crash by showing a non- useful variant of the critical error dialog if it runs out of retries, e.g. when using a TSR to make writes always fail, as opposed to failures which go away when retrying. If you can determine a reliable way for ALL disks to come out of stand-by mode, i.e. at what point UIDE should have a long time-out value, I can program that. But, it must be COMMON to all drives, NO exceptions, or it might cause just as much TROUBLE as it resolves! You can use FDAPM to spin down disks at once: It sends the raw command (e0, standby) for that to the first 4 disks when you select spin down and sends immediate idle (e1, idle) to wake up disks explicitly. However, the latter is not needed as the disk will automatically spin up when accessed again. BIOS, DOS (FreeDOS) and lbacache seem to have no problem with this but of course it would be better to first check the disk self-id, to only send those commands to drives which care for them. The I/O sequence for the primary controller is: out 0x1f6,0xa0 for master or b0 for slave (non-lba command here) wait (just a tiny bit) out 0x1f7,command (0xe0 standby/spin down - 0xe1 idle/spin up) wait (again) ... repeat for port 0x176 / 0x177 for secondary controller. Related commands: e6 suspend/sleep (you want to avoid this, as waking up would need a drive reset), e5 check power state (does not cause a wake up), ec read self-id (read port 0x1f0 many times to get 512 bytes of data as soon as drive ready?) and last but not least e3 set idle / spin-down timer :-) My notes say Seagate Barracuda use 8-12 Watts between idle and working-and-seeking while using 25 Watts for a few secs while spinning up, 1 Watt in standby and even less in sleep. The fact that I cannot grep standby-specific error handlers in lbacache probably means two things: Lbacache does not have to retry I/O itself, because DOS does that already and second neither DOS nor BIOS try to reset harddisks when I/O fails, nor does lbacache do that for them. I think if your disk is in sleep / suspend or even bus tri-state mode, it would be as if it is not really there at all and the BIOS would run in a bad timeout or similar as it just does not expect that case. In short: Please check whether fdapm spindown has adverse effects on anything in UIDE context and implement sending a 0xe3 set idle timer to X minutes UIDE command line option (where you convert X to a suitable byte of N*12 if N at most 20, otherwise X = 240 + round(N/30) with a maximum N = 330), at your choice either for sending the 0xe3 to all drives or only to certain drives based on a choice of the user or 3rd only to drives for which setting the idle timer is useful, based on checking the drive's self-id at UIDE driver start. To already answer some possible questions: CD/DVD drives do not seem to have problems with the immediate standby or immediate idle, but hdparm -I does not list anything on this topic for my DVD drive (only lists supported PIO / DMA modes) while the report for my harddisk is far more verbose: Queue depth: 32 Standby timer values: spec'd by Standard, no device specific minimum ... Recommended acoustic management value: 254, current value: 128 (this is about how fast and noisy seeks should be done etc) Supported features for the harddisk: SMART, Power Management, Write Cache, Look-Ahead, Automatic Acoustic Management, 48-bit LBA, Cache Flush, SMART Logging and SMART Self-Test, NCQ, 3Gb/s SATA, Host-initiated bus(?) (says interface) Power Management, (optional) Persistent Settings (preserve over reboot etc), various SMART SCT I/O and a number of other features. No power saving related features are reported for my CD/DVD drive and running smartctl -d ata -a for it for example just returns the model, support for ATA7, no SMART support. Trying with -d sat (SCSI to ATA layer, 16 byte variant) is even worse, the drive does not even give a model name then. As I am evil, I just sent -y standby, --idle-immediately as well as --idle-unload (also parks heads?) and -Y sleep to my CD/DVD drive via hdparm anyway. Drive reactions/symptoms: None that I noticed at all for --idle-*, a tiny delay for -y and a bigger delay together with a kernel log message saying that the SATA link got reset when I used the -Y command :-p Setting the idle timeout (hdparm -S) for my CD/DVD drive, which as mentioned claims to not support any
Re: [Freedos-user] UIDE vs drive power management spin down timers
Eric, I read through and understood all your comments about hard-disk power management, etc. My problem is: I am not-interested in being the one who does power management. If DOS or the BIOS wants to save power thru putting disks into stand-by mode, let them do it. UIDE is a disk I-O driver, not a power-management tool, and I desire to keep such things OUT of UIDE's logic! Re: handling disk drives which ARE in stand-by mode, if all I need to do is allow some more time for them to spin-up, that is relatively easy. UIDE's CD/DVD logic currently allows 7 secs. for spin-up and 3 seconds for track-to-track seeks, which I had forgotten -- I had not looked at that logic for almost 5 years! Assuming 7 seconds should be long enough! for a hard disk, as well, I can simply use that value as a timeout during disk I-O, not the current 400-msec timeout. Shall experiment re: this idea. Might cause some confusion among UIDE users, who will now see a 7-second delay in some error handling. But, if UIDE needs only a timeout change to handle sleeping hard disks, it might be worth updating only 1 byte in its DoIO subroutine! Jack R. Ellis -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] UIDE vs drive power management spin down timers
Jack, I read through and understood all your comments about hard-disk power management, etc. My problem is: I am not-interested in being the one who does power management. If DOS or the BIOS wants to save power thru putting disks into stand-by mode, let them do it... There is not much to do there, as you only tell the disk once and then the disk itself does the rest. But it would be good to know from you that UIDE is (as predicted) happy to wait a moment for idle disks to spin back up as that in fact does not need any explicit handling by UIDE anyway. However, I would be happy if UIDE could do the sending of the idle timer config command to the disk because: It already does raw drive I/O anyway and it already has some command line parser anyway so it would only take a few more (non-resident) bytes to let UIDE send this command when the user puts the corresponding command line option during UIDE start-up. That way, no separate tool would be needed which would duplicate existing UIDE logics. UIDE is a disk I-O driver, not a power-management tool, and I desire to keep such things OUT of UIDE's logic! Yet UIDE already probably does drive setup communication with the disk for selection of the right communication speed so my point is it would be only a small step to make it possible to send other drive (e.g. idle timer) setup commands with it. relatively easy. UIDE's CD/DVD logic currently allows 7 secs. for spin-up and 3 seconds for track-to-track seeks, which I had forgotten -- I had not looked at that logic for almost 5 years! Interesting. So it can in fact report a time-out, but that should simply make DOS try again. As FreeDOS tries 5 times, you get much more than 3 or 7 seconds in the end, depending on which timeouts are used for int 13 functions 0, 2, 3, 42 and 43. Long enough :-) Assuming 7 seconds should be long enough! for a hard disk, as well, I can simply use that value as a timeout during disk I-O, not the current 400-msec timeout. Shall experiment re: this Thanks - and see above. idea. Might cause some confusion among UIDE users, who will now see a 7-second delay in some error handling. Good question. This would only make delays longer for errors that would never end without explicit error handling but I understand that users could still notice. For example I remember that using CompactFlash CF cards with a (purely mechanical) IDE adapter plug can have such hangs for low quality cards - in particular when you combine that plug with a SATA-IDE adapter with cheap chipset. So I guess such hangs would get longer with longer timeouts, as it might take the driver longer to give up the access attempt and decide to give the drive a smack of reset to reactivate it no matter whether it is the driver or just DOS which says reset. But, if UIDE needs only a timeout change to handle sleeping hard disks, it might be worth updating only 1 byte in its DoIO subroutine! Nice, thanks :-) Eric PS: Of course a stall/crash of a CF/SD/... card affects any OS. -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] UIDE vs drive power management spin down timers
Eric, ... My problem is: I am not-interested in being the one who does power management. If DOS or the BIOS wants to save power thru putting disks into stand-by mode, let them do it... There is not much to do there, as you only tell the disk once and then the disk itself does the rest. Amen!, so let the user handle this thru the BIOS setup routines and let the BIOS tell the disk what to do during system boot! BIOS vendors have many more programmers than just me by myself! But it would be good to know from you that UIDE is (as predicted) happy to wait a moment for idle disks to spin back up, as that in fact does not need any explicit handling by UIDE anyway. UIDE's CD/DVD logic is happy to wait for up to 7 seconds, and I will look into changing its disk logic from 400-msec to 7 seconds as well. However, I would be happy if UIDE could do the sending of the idle timer config command to the disk because: It already does raw drive I/O anyway and it already has some command line parser anyway so it would only take a few more (non-resident) bytes to let UIDE send this command when the user puts the corresponding command line option during UIDE start-up. That way, no separate tool would be needed which would duplicate existing UIDE logic. Actually, UIDE has NOT changed any disk-configuration settings by the BIOS since late 2005, when I got into TROUBLE doing so with some BIOS programs! UIDE now only reads I-O and DMA addresses for a disk from the BIOS, then runs a disk however the BIOS set it up. That, also, is something I want to LEAVE up to the BIOS, as I don't want any MORE trouble by changing BIOS settings again! UIDE is a disk I-O driver, not a power-management tool, and I desire to keep such things OUT of UIDE's logic! Yet UIDE already probably does drive setup communication with the disk for selection of the right communication speed so my point is it would be only a small step to make it possible to send other drive (e.g. idle timer) setup commands with it. No, sir! UIDE does NOT change any communication-speeds nor ANY other BIOS settings for disks, not since 2005, as I noted above! relatively easy. UIDE's CD/DVD logic currently allows 7 secs. for spin-up and 3 seconds for track-to-track seeks, which I had forgotten -- I had not looked at that logic for almost 5 years! Interesting. So it can in fact report a time-out, but that should simply make DOS try again. As FreeDOS tries 5 times, you get much more than 3 or 7 seconds in the end, depending on which timeouts are used for int 13 functions 0, 2, 3, 42 and 43. Long enough :-) Any hard-disk function but 2/3/42/43 (reads and writes) is passed to the BIOS, so function 0 would not be so timed-out by UIDE. Nor would UIDE ever declare a timeout -- CD/DVD errors currently post only general error in such cases, and hard-disk errors would post only whatever hardware error applies to that part of DoIO which noted the timeout, likely a DMA error for most cases. Not a big problem. Disk/CD/DVD errors are few and far between, and people already know that a lot of DOS programs will only display Error!, leaving exactly WHAT error it was for diagnostic programs, etc.! ... Might cause some confusion among UIDE users, who will now see a 7-second delay in some error handling. Good question. This would only make delays longer for errors that would never end without explicit error handling but I understand that users could still notice. For example I remember that using CompactFlash CF cards with a (purely mechanical) IDE adapter plug can have such hangs for low quality cards - in particular when you combine that plug with a SATA-IDE adapter with cheap chipset. So I guess such hangs would get longer with longer timeouts, as it might take the driver longer to give up the access attempt and decide to give the drive a smack of reset to reactivate it no matter whether it is the driver or just DOS which says reset. If DOS does 5 retries, as you indicate, this would cost the user a maximum of 35 seconds (my 7 seconds * 5 tries) and thus is NOT any sort of an indefinite hang!I would indicate in UIDE's README that an actual [rare!] disk error may now take that long, before DOS gives-up on it and reports something to the user. But, if UIDE needs only a timeout change to handle sleeping hard disks, it might be worth updating only 1 byte in its DoIO subroutine! Nice, thanks :-) That was only my Thought while eating breakfast! this morning, but I shall test it out, later today! Jack R. Ellis -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Freedos-user
Re: [Freedos-user] UIDE vs drive power management spin down timers
Jack, There is not much to do there, as you only tell the disk once and then the disk itself does the rest. Amen!, so let the user handle this thru the BIOS setup routines and let the BIOS tell the disk what to do during system boot! BIOS vendors have many more programmers than just me by myself! I have not yet seen a desktop BIOS which implements this, alas. I do have an adware DOS tool for it, showing a splash screen for a BBS or similar when you run it and of course bigger than needed, but free. Actually, UIDE has NOT changed any disk-configuration settings by the BIOS since late 2005, when I got into TROUBLE doing so with some BIOS programs! UIDE now only reads I-O and DMA addresses Interesting, but which trouble did which setting cause? Any hard-disk function but 2/3/42/43 (reads and writes) is passed to the BIOS, so function 0 would not be so timed-out by UIDE. Nor would UIDE ever declare a timeout Why not? There is an error code (0x80) defined for that in int 0x13. If DOS does 5 retries, as you indicate, this would cost the user a maximum of 35 seconds (my 7 seconds * 5 tries) and thus is NOT any sort of an indefinite hang! What I meant is that when the disk is in a state where only a reset can make it continue, the driver will wait 7 seconds. If it is in a state where nothing will make it continue (e.g. un-hotplugged it?), DOS will take 35 seconds until it displays an error message. In the 7 second case, the user will in the worst case see a delay of 7 sec plus the time needed to spin up, but more likely only the always- present delay caused by the time needed to spin up. That was only my Thought while eating breakfast! this morning, but I shall test it out, later today! Have a nice afternoon then :-) Eric -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] UIDE vs drive power management spin down timers
Eric, I have not yet seen a desktop BIOS which implements this, alas [disk spin-down timeouts, etc.]. I do have an adware DOS tool for it, showing a splash screen for a BBS or similar when you run it and of course bigger than needed, but free. Desktop BIOS routines are usually not-interested in saving power thru spin-down timeouts or other such tricks. Laptop BIOS routines ARE interested, since their power is limited when using batteries. Thus it is mainly laptops we address here, and their BIOS routines DO have the needed hard-disk logic. Actually, UIDE has NOT changed any disk-configuration settings by the BIOS since late 2005, when I got into TROUBLE doing so with some BIOS programs! UIDE now only reads I-O and DMA addresses Interesting, but which trouble did which setting cause? With a few BIOS routines back in 2005 (maybe obsolete, now), setting any UltraDMA mode OTHER than what the BIOS set did not work! To be safe, I got RID of such mode-set logic in my drivers, back then. Any hard-disk function but 2/3/42/43 (reads and writes) is passed to the BIOS, so function 0 would not be so timed-out by UIDE. Nor would UIDE ever declare a timeout ... Why not? There is an error code (0x80) defined for that in int 0x13. Note in my drivers' UltraDMA DoIO subroutine, it is always waiting for either controller/drive ready or DMA end. If those events do not occur, hard to tell if the controller/disk has failed or if they just took too long.I have assumed a disk will finish I-O in at most 400 msec, and if not, it was a hardware failure, not a timeout. So, I have never used BIOS code 080h. Same situation even if the DoIO timeout becomes 7 seconds, to handle disk spin-up. No way I can know if the hardware failed, so I doubt I can use code 080h. If DOS does 5 retries, as you indicate, this would cost the user a maximum of 35 seconds (my 7 seconds * 5 tries) and thus is NOT any sort of an indefinite hang! What I meant is that when the disk is in a state where only a reset can make it continue, the driver will wait 7 seconds. If it is in a state where nothing will make it continue (e.g. un-hotplugged it?), DOS will take 35 seconds until it displays an error message. In the 7 second case, the user will in the worst case see a delay of 7 sec plus the time needed to spin up, but more likely only the always- present delay caused by the time needed to spin up. Understood, if in fact DOS issues a drive-reset on any error. Also, note that my drivers do NOT allow removable or hot-pluggable HARD disks, since I cannot be sure all DOS kernels can handle media-change events in their HARD-disk logic! Jack R. Ellis -- Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
