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
