Xref: utzoo comp.unix.xenix:2290 comp.unix.microport:664 comp.periphs:968
Path: utzoo!attcan!uunet!steinmetz!davidsen
From: davidsen@steinmetz.ge.com (William E. Davidsen Jr)
Newsgroups: comp.unix.xenix,comp.unix.microport,comp.periphs
Subject: Re: Thoughts needed
Keywords: Compaq xenix microport multi-user multiport
Message-ID: <10889@steinmetz.ge.com>
Date: 18 May 88 19:30:12 GMT
References: <4144@orstcs.CS.ORST.EDU> <224@obie.UUCP> <1988May10.181259.1971@utzoo.uucp> <230@obie.UUCP> <3771@lynx.UUCP>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 22

In article <3771@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes:
| In article <230@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes:
| >                               . . .  MS-DOS allows you to load your
| >program and write files on the disk in a fairly reasonable manner, and
| >won't get in the way of your response time (hopefully).  . . .
| 
| ``Reasonable'' is in the eyes of the reasoner.  Because (at least in
| the 386 thing we have here) the AT hard disk controller does not use 
| the DMA controller, the CPU must poll when transferring.  The MS-DOS
                      ^^^^^^^^^^^^^^^^^
| driver keeps interrupts off while doing this, bringing the interrupt
| response time down by quite a bit.

  As I'm sure a lot of people will tell you, that's the way the beast is
implemented, not the way it *must* be done. Xenix and OS/2 seem to be
able to run just fine using DMA mode and interrupts. The problem is that
MS-DOS is more or less a knock off of CP/M, and since it's not multi
tasking it has nothing better to do with the CPU than wait.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me