Hi Eric,
First some considerations, comments bellow:
I consider using FDAPM (and a few more generic programs) in two situations:
a) my own machine in real dos: here I can use more features as I can test end fine-tune them, but on the other hand I have a far better disciplined use and often can use some workaround problems.
b) my own machine in Dosemu: this is new to me and I will adjust slowly. It has an advantage that often it better to use a Linux program in another windows than make it work in Dosemu...
c) general instalation in user machines: this has to work for every machine out there... and it has to be done one step at a time, even if this means smaller benetits. In case of FDAPM i wish only to keep CPUs cooler as this is the number one problem in my problem list. But if something does not work but I can give a good warning message, it is not so bad as this can be used to force the user to upgrade o fix his machine.
How can this be configured? I am only concerned because of some old discussion (IIRC in this list, so maybe you remember it) about some machines causing power-supply glitches because of the too sudden power reduction with HLT. The idle call could be used in case of a machine having sporadic problems. In the long run we will know for sure if this problem is real...Am I safe if I use only APMDOS?APMDOS - which is the only TSR mode of FDAPM - uses both HLT and the int 15.5305 CPU idle call (you can configure which to use, but default is to use both)
in the following situations: "wait for key" (not: check for key), int 2a.84, int 28 (DOS idle).
Ok, more comments bellow
It could happen that HLT (which causes Stop Grant on some modern CPUs to save more energy) stops the time stamp counter (-> RDTSC). Would be nice if somebody could tell me if that happens.
> I have read it in too many places, so I believe that it will happen some time. I read some news that new AMD cpus have another counter that does not stop and thus can be reliable for timing, if I find how to use it then maybe I can stop using the hardware timing.
2) Aparently STATS apply to all the time interval from going TSR. How can I reset them to fine tune my main program?You would have to reset onTicks and idleTicks... which are hopefully counted properly enough by handlers.asm... The non-idle ticks are counted when int 16 "check for key" or int 2f.ae are called. If those are not called for a long time, you end up in a situation where the measured uptime is too small and you have more than 100% idle time according to FDAPM. If you think this is a problem, then please suggest some other hooks which should also trigger uptime update (preferrably not simply hooking int 1c, or would that be the best option?).
Suggestion: just display ">90%" or anything non commital...
When FDAPM displays the stats, it copies them from the TSR to the non-TSR instance. Nothing resets the counts in the TSR yet, but I can add such a function if you like. I can also add the mentioned int 1c hook when I am updating FDAPM anyway... Comments please.
What I was thinking about is just a command line method to reset the TSR conters. The problem in mind is to fine tune a specific program with a sequence like: reset stats - run program - read stats. The reset could be added if a APMDOS is reissued with the TSR already installed.
>3) I intend to use it with a program in OpenWatcom-3 in PM. The problem is that it is not allowing any saving :(Same for DJGPP-compiled SSH2DOS (sshdos.sourceforge.net) :-(.
The main program loop is: check keyboard via bios, check mouse movement (cursor is in sw not the driver), check timers (3 events/s) and when the the event queue is empty that is it.
As explained above, CHECK keyboard does not count as being idle. However, you can just use the HLT assembly language command in your main loop yourself - this stops the CPU until the next hardware interrupt. WAIT for keyboard would count as being idle, but it would slow down your loop (freeze whenever no key pressed!). I see no way how FDAPM could decide that your main loop involves being idle - for FDAPM, your program looks as if it is checking keyboard and mouse as often as possible, and it cannot decide when your program is bored, even though FDAPM could be made clever enough to know when keyboard / mouse has "no news to report". In Linux, your task would yield / wait for "event on any file handle" (using select(), sleep(), or using signal handlers together with "wait for data" instead of "select to check for data"), Linux would switch to the next task, and if no tasks are left waiting for CPU time, then the last task - the kernel "idle task" - would do just that: invoke HLT.
I can find out when the program is idle. Due to the possible problem that I mentioned above, I am not sure that issuing a HLT is safe. BUT is there a save way to call FDAPM in memory? This could be safer as it would use the configured method. I cannot stay frozen until a key is pressed, but if the machine unfreezes due to any other IRQ (including back-ground communications) I can just freeze again..
Is this the way Int28 works? Should I just insert it in my loop when I am idle?
What about DosEmu? Will Int28 free processor time? Will it return if a) a key is available b) mouse move/click c) Int1C occured?
I feel like my questins are somewhat wrong... There is something about interacting between programs and FDAPM (and Dosemu) that I didn't understand.
For Win9x, you have tools like RAIN or WATERFALL (freeware) to call HLT...
I am not using Windows much.
"The box said: requires Win9x, 2k or better. So I installed Linux"
M$ forbid me to install Win9x in my notebook unless I paid US$300, I was an eventual Linux user, now I am an eventual Windows user :)
Is USB mouse in DOS handled via bios OK?If your BIOS supports USB mouse, then it will simulate a PS/2 mouse from it. Mouse drivers which do NOT use direct hardware access should work with that, e.g. CuteMouse 1.9 will work, 2.0 will not. If you load own drivers for OTHER USB devices, the BIOS will usually loose all control over USB, and you would have to load DOS drivers for ALL USB devices (or for NONE, and use only those USB things for which you have BIOS drivers). However, you can conceivably use DOS drivers for some of your USB controllers if BIOS only grabs those USB controllers which have supported devices like mice plugged in... Modern PCs often have 2-4 independent USB controllers.
USB mouse is just a convenience in my motebook because that way I can use simultaneously the touchpad and the mouse. It works fine and I do not intend to use any other USB device in DOS. My concern was itÅ iteraction with FDAPM, from the above I believe that in APMDOS mode there is no problem. I will test if it can wake up from SUSPEND and let you know.
You can also spin down disks (IDE: FDAPM, using hardware access, SCSI: using ASPI SCSIMGR$ device drivers and http://home.arcor.de/g.s/ ???) to save 5-10 Watts per disk,
This is becoming a new source of concern: some new disks are getting too hot and possibly a spindown could do them some good. I see that FDAPM has this functionalyty, could it handle it through some special call in a way to make it both safe and transparent? When to spin-down would be no problem as I already have a timer that flushes buffers, but is a command needed to spin-up?
and throttle the whole CPU speed (to N*12.5%) with http://www.oldskool.org/pc/throttle/ ... If throttling turns out to be effective, I could try to add that to FDAPM.
IMHO a) this is too much HW dependent, b) this will degrade system response time for user input, c) FDAPM saves power with almost no performance penalty which is a better aproach.
CPUs which support SpeedStep or Cool'n'Quiet allow you to reduce power consumption a lot: For example Athlon64 at 40% of max speed, with lowered core voltage, takes only 24% of the top power consumption, and Sempron takes 32% power at 55% speed. Other CPUs take 89/66/35 Watts at 2/1.8/0.8 GHz ... Even for K6-2 333 MHz you have a big difference between worst case (19 Watts), normal load (not keeping all CPU components busy all the time) (11 Watts) and HLT (4 Watts). For Pentium M and Celeron M, you have 22/25 Watts (2 GHz?) normally and 7/10 Watts in HLT - those also support deep and (not Celeron M) also deeper sleep, which makes more components of the CPU sleep (5/6 Watts, deeper sleep of Pentium M even less than 1 Watt).
Deep sllep could be nice for suspend because of much lower consuption, but may be overly complicated and it will benefit only few machines.
You can compare HLT / StopGrant with S1 idle state (CPU C1 idle state). To support C2/C3 sleep states, you often need extra (ACPI) drivers, which is probably not too useful in DOS (HLT is not much worse than deepsleep, and you can keep the CPU throttled all the time to save even more energy). The next useful state would be S2 standby, which is not supported by all BIOSes and systems: For S2, you need extra ACPI drivers, and have to save ALL (including configuration and protected mode stuff and all floating point, MMX, whatever) CPU state and call WBINVD (flush cache) before you enter that mode: S2 turns off the CPU (!) and reboots to wake up. The wake up jumps to a handler (which you have to provide) which copies all state information back to your CPU. I guess "deepersleep" on Centrino works without that complex step, by allowing a state-preserving minimum power mode for the CPU.
Even Linux is having a lot of problems with ACPI, so IMHO you should avoid it ;-)
Talking about Sn states: S3 is suspend to RAM - some APM BIOSes support that (very few (?) even do suspend to DISK S4 for you) - which can be triggered by FDAPM SUSPEND, but only if your BIOS supports APM. S1 is STANDBY, and PCISLEEP S should get close to that even without APM BIOS (PCISLEEP just HLTs the CPU and tells all devices for which no extra drivers are needed to do that to enter a sleep state). Finally, S5 is soft-off, and it would be interesting to make FDAPM able to power off the system without APM BIOS help. You can try my PNPOFF tool on systems where newest FDAPM fails, and if that STILL fails, I would have to make FDAPM or PCISLEEP understand a bit of ACPI (full ACPI support would require a binary of 70k or more uncompressed size, containing complex parsers and a virtual machine, see www.acpi.info). However, you have to tell me if not having to press the power button with your fingers is worth the effort of improving FDAPM POWEROFF.
Something between S1 and S3 can be reached by spinning down disks with FDAPM or SCSISPDN and then using PCISLEEP V, which disables the screen and then suspends the VGA. For the wake-up after that, the VGA BIOS is "rebooted", which can crash for modern VGAs, in particular when you have EMM386 loaded. But it is a very interesting experiment to try it! In particular: How much energy does it save? Suspending other devices is not supported - 1. because I do not know how to re-init them and 2. because they only use little energy as far as I can tell. Feedback welcome! PCISLEEP V also odoes the same SLEEP step as PCISLEEP S and of course also HLTs the CPU.
My opinion about all this is: overly complicated !
=> "fdapm apmdos": it's good, safe and doesn't impact performance much
=> "Suspend" is good, aparently safe and runs in most HW. I am not sure if I can put my notebook in it's bag (no ventilation) and take it home in that state...
Other methods should be used for more complex operating systems like Linux. I look like there are lots of problems involved, so much that there is a Linux hibernation alternative that is 100% software!
I have a view of DOS as being very usefull but used in controled situations (my case is included, as are embeded systems) and that too complex and generic problems should be taken to mode complete OSes. Embeded systems have a different aproach to the performance problem: the peak performance is the main concern and they are engeneered to withstand that continuosly. APMDOS mode can help in lenghtening equipmente life witout loosing performance so I believe that this is an important feature.
Alain
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
