jer@pender.ee.upenn.edu (Joel Ratsaby) (06/10/91)
Is the architecture of 486 ISA (Not EISA) machine fit for Unix or is the 32 bit capability of the 486 is masked by the ISA architecture ? If I use DOS 5.0 can I do multitasking (without Windows package) and is the 32 bit capability of the 486 masked by DOS ? I would appreciate any explanation or pointers to articles concerning the above. thanks --Joel
pshuang@ATHENA.MIT.EDU (06/11/91)
In article <44390@netnews.upenn.edu> jer@pender.ee.upenn.edu (Joel Ratsaby) writes: > Is the architecture of 486 ISA (Not EISA) machine fit for > Unix or is the 32 bit capability of the 486 is masked by the > ISA architecture ? > > If I use DOS 5.0 can I do multitasking (without Windows package) > and is the 32 bit capability of the 486 masked by DOS ? 486 ISA machines are quite fit for UNIX, as are 386 ISA machines. You won't get the same kind of snappy performance as the mid to high-end workstations, but it will be acceptable, especially if you spend a fair amount of money to insure that the machine is equipped with a very fast and large disk drive and a speedy display adaptor board which can support a high resolution screen and possibly has a graphics coprocessor on it. The bus does not seem to be as huge an issue as IBM would have had you believe with their push for MicroChannel architecture, according to PC Magazine tests about a year back, when they concluded that for most setups and users and applications, ISA vs. EISA vs. MicroChannel made little difference to real-world throughput. In any case, ISA's 16-bit bottleneck applies only to I/O and does not affect the 32-bit processing speed of the i486 CPU, unless you are supplying memory via a expansion board on the bus, which would be plain silly. DOS 5.0 does not provide multitasking, but only task switching, and according to Bill Gates at the BCS meeting tonight, it never will. Since DOS runs the i386 and i486 chips in real mode (for compatibility with the 8088 chip), in a sense their 32-bit capabilities are masked and performance reduced, and in a sense they aren't. To a small extent, performance in real mode is enhanced because memory accesses are slightly slower in protected mode (because it does take a little time to provide the memory protection, after all). However, because DOS software rarely takes advantage of the "newly" introduced 32-bit instructions in these chips or their ability to access directly more memory, often they don't take full advantage of the full capabilities of the new chips. Several very demanding applications (AutoCAD, Paradox) exist in both DOS versions (compatible with any machine from 8088 and up) and in special 386 versions. Running them on the same machine, I believe you can see a considerable speed-up, maybe on the order of 100%, of the 386-specific version over the general version. Singing off, UNIX:/etc/ping instantiated (Ping Huang).
david@kessner.denver.co.us (David Kessner) (06/11/91)
In article <9106110417.AA06408@w20-575-117.MIT.EDU> pshuang@ATHENA.MIT.EDU writes: >The bus does not seem to be as huge an issue as IBM would have >had you believe with their push for MicroChannel architecture, according >to PC Magazine tests about a year back, when they concluded that for >most setups and users and applications, ISA vs. EISA vs. MicroChannel >made little difference to real-world throughput. In any case, ISA's >16-bit bottleneck applies only to I/O and does not affect the 32-bit >processing speed of the i486 CPU, unless you are supplying memory via a >expansion board on the bus, which would be plain silly. Ah, no. Several points I'd like to make. The "test" PG Mag did a while back only tested the busses with MS-DOS! In fact, it was mentioned in an editorial in that same issue that they planned to have another issue comparing ISA/EISA/MCA under more favorable conditions like UNIX and Novell-386, etc. Well, as you and I know, they never had that issue. In that same editorial, it was mentioned that they expected EISA/MCA to perform much better than ISA under UNIX. Testing any high-performance hardware (CPU, Hard drives, busses, etc) under MS-DOS is stupid. MS-DOS is more of a bottleneck than the hardware is. Disk transfer rates for EISA is only about 10-20% faster than ISA (after all, you can only get the data off the disks so fast). The REAL benifit of EISA comes into play when a multitasking system is being used. When a UNIX task requests a block from the disk (on an ISA bus), the CPU goes off and grabs that block-- it takes 100% of the CPU time to get that block since the ISA bus and hard drive controllers are brain-dead. When an EISA based UNIX system requests a disk block, the OS tells the controller to read a block into memory. It then puts that task on hold (until the block is read in), meanwhile it goes off and runs another task. So, while the one task is waiting for the disk controller, others are still being executed-- where as an ISA based machine will pause all tasks since the CPU is tied up doing the disk transfer. MS-DOS cannot take advantage of this, since MS-DOS is not multi-tasking. In fact, things like Desqview and Windows also cannot do this, since they are built on MS-DOS's file system. Putting RAM on the EISA bus is silly, I agree. The EISA bus, like other busses, should only be used for I/O. I/O, however, is more important when you are using a 20 MIPS CPU. -- David Kessner - david@kessner.denver.co.us | 1135 Fairfax, Denver CO 80220 (303) 377-1801 (p.m.) | Reunite PANGEA! Compuserve? Isn't that some sort of FIDO BBS? |
pshuang@ATHENA.MIT.EDU (06/11/91)
In e-mail, jer@pender.ee.upenn.edu asked on Tue, 11 Jun 91 00:56:29 EDT: > Is Task Switching means that the processor does Time Division > Multiplexing on the processes ? if so then how does it differs from > multi-tasking on Unix ? Or does Task switching means that the user > can "stack up" TSRs in memory and in reality only one program is > running until the user "switches" to another program that was asleep Strictly speaking all versions of multitasking on single processor machines must perforce use some form of task switching. The clarification is that (unless you're talking to a bunch of system programmers) usually the term "task switching" is reserved situations where it is up the the end user to signal to the computer to start running a different application (via a hotkey or by some other means) which had been asleep until now, whereas "true multitasking" refers to the case where the computer uses some periodic signal, usually the system timer, to switch between applications for you so that they all have a chance to do something... exactly what you refer to by time division multiplexing. It is not very different from how UNIX multitasks, although the details of the implementation differ. [There's also a level of multitasking "below" time-slicing usually labeled "cooperative", where it is up to the application to call a certain system function every so often to give up the CPU voluntarily. This is the form of multitasking you find in Apple's Multifinder as well as between Windows 3.0 programs (but not between Windows 3.0 and DOS programs). Its failing is that an application which is not properly written or which crashes will never yield the CPU back to the system.] You will find task switching in shareware products such as Back and Forth and commercial products such as Software Carousel and Switch-It. Desqview and Windows 3.0 can provide true multitasking given the right hardware, or can provide task switching on lesser hardware. OS/2 also provides both, but in a more robust implementation (protects processes from trashing each other and provides better interprocess communication as UNIX does). You can also get true UNIX for i386/i486 boxes. Singing off, UNIX:/etc/ping instantiated (Ping Huang).
tgoose@eng.umd.edu (Jason Garms) (06/12/91)
In article <9106110417.AA06408@w20-575-117.MIT.EDU>, pshuang@ATHENA.MIT.EDU writes: > In article <44390@netnews.upenn.edu> jer@pender.ee.upenn.edu (Joel > Ratsaby) writes: > > > Is the architecture of 486 ISA (Not EISA) machine fit for > > Unix or is the 32 bit capability of the 486 is masked by the > > ISA architecture ? > > > > If I use DOS 5.0 can I do multitasking (without Windows package) > > and is the 32 bit capability of the 486 masked by DOS ? > > 486 ISA machines are quite fit for UNIX, as are 386 ISA machines. You > won't get the same kind of snappy performance as the mid to high-end > workstations, but it will be acceptable, especially if you spend a fair > amount of money to insure that the machine is equipped with a very fast > and large disk drive and a speedy display adaptor board which can > support a high resolution screen and possibly has a graphics coprocessor > on it. The bus does not seem to be as huge an issue as IBM would have > had you believe with their push for MicroChannel architecture, according > to PC Magazine tests about a year back, when they concluded that for > most setups and users and applications, ISA vs. EISA vs. MicroChannel > made little difference to real-world throughput. In any case, ISA's > 16-bit bottleneck applies only to I/O and does not affect the 32-bit > processing speed of the i486 CPU, unless you are supplying memory via a > expansion board on the bus, which would be plain silly. [Stuff deleted] > Singing off, > UNIX:/etc/ping instantiated (Ping Huang). There are two major differences in running UNIX on an ISA and an EISA bus. The first is that on an ISA bus, expansion cards cannot address an memory you may have over 16MB. For some people this may not be a problem, for others it might. The second thing is that EISA boards provides significantly better performance in a network than ISA machines. If you are looking to use it as a server, then the EISA machine would be a much better choice. Jason Garms tgoose@eng.umd.edu
markb@unix386.Convergent.COM (Mark Beyer) (06/13/91)
tgoose@eng.umd.edu (Jason Garms) writes: >There are two major differences in running UNIX on an ISA and an EISA >bus. ... >The second thing is that EISA boards provides significantly better performance >in a network than ISA machines. You may be right, but it might be useful if you gave some detail as to why EISA network adapters would be better. The potential reasons I see are: 1) EISA has a better bus mastering scheme. 2) The data path is wider. 3) The data rate can be higher. But, then you'd have to support these reasons with measurements or more detailed models. For example, I'd like to know how many commercial protocol stacks for 486 machines are capable of maxing out the ethernet with an EISA interface. If your TCP stack just can't pump data down to the bus adapter fast enough or, more likely, it can't receive it fast enough, maybe you're OK with the (cheaper ?) ISA interface. Any hard data ? Regards, Mark -- Mark Beyer markb@convergent.com {uunet,sun,decwrl,hplabs}!pyramid!ctnews!markb
neese@adaptx1.UUCP (06/15/91)
>>There are two major differences in running UNIX on an ISA and an EISA >>bus. ... > >>The second thing is that EISA boards provides significantly better performance >>in a network than ISA machines. > >You may be right, but it might be useful if you gave some detail as to why >EISA network adapters would be better. The potential reasons I see are: > > 1) EISA has a better bus mastering scheme. > 2) The data path is wider. > 3) The data rate can be higher. > >But, then you'd have to support these reasons with measurements or more >detailed models. For example, I'd like to know how many commercial protocol >stacks for 486 machines are capable of maxing out the ethernet with an EISA >interface. >If your TCP stack just can't pump data down to the bus adapter >fast enough or, more likely, it can't receive it fast enough, maybe you're >OK with the (cheaper ?) ISA interface. There is more to it than that. I doubt very many TCP implementations, under UNIX and Novell, for example could max out the bandwidth of the wire, but there are other considerations. Using the 32 bit EISA bus and bus mastering, the ethernet card would utilize less of the bus I/O time, therefore allowing more time for other I/O (such as disk) to occur. This is more relevant in a multi-tasking environment, but something to consider. So many have looked at the EISA implementation from the perspective of, "WOW, now I can move data at 33MBytes/sec!" Well, this isn't very pratical given the current state of I/O adapters/controllers and the peripherals that exist today (and for some time on the future). But with that speed and a proper buffering implementation on the adapter/controller, more I/O's can be generated per slot than could ever be done on the ISA architecture. Just something to consider. Roy Neese Adaptec Senior SCSI Applications Engineer UUCP @ neese@adaptex uunet!cs.utexas.edu!utacfd!merch!adaptex!neese
edhall@rand.org (Ed Hall) (06/18/91)
In article <1991Jun11.062033.5218@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: >The REAL benifit of EISA comes into play when a multitasking system is being >used. When a UNIX task requests a block from the disk (on an ISA bus), the >CPU goes off and grabs that block-- it takes 100% of the CPU time to get that >block since the ISA bus and hard drive controllers are brain-dead. No, *some* ISA controllers are brain-dead. Not all. >When an EISA based UNIX system requests a disk block, the OS tells the >controller to read a block into memory. It then puts that task on hold >(until the block is read in), meanwhile it goes off and runs another task. >So, while the one task is waiting for the disk controller, others are still >being executed-- where as an ISA based machine will pause all tasks since the >CPU is tied up doing the disk transfer. Not with a bus-mastering controller. Most popular in the UNIX world is the Adaptec 1540-series SCSI controller. This type of controller will grab the bus and run it at full speed while the CPU goes off and does other things. It can easily transfer data at the fastest speeds SCSI can deliver. -Ed Hall edhall@rand.org
neese@adaptx1.UUCP (06/18/91)
>In article <9106110417.AA06408@w20-575-117.MIT.EDU> pshuang@ATHENA.MIT.EDU writes: >>The bus does not seem to be as huge an issue as IBM would have >>had you believe with their push for MicroChannel architecture, according >>to PC Magazine tests about a year back, when they concluded that for >>most setups and users and applications, ISA vs. EISA vs. MicroChannel >>made little difference to real-world throughput. In any case, ISA's >>16-bit bottleneck applies only to I/O and does not affect the 32-bit >>processing speed of the i486 CPU, unless you are supplying memory via a >>expansion board on the bus, which would be plain silly. > >STUFF DELETED< >Disk transfer rates for EISA is only about 10-20% faster than ISA (after all, >you can only get the data off the disks so fast). True, for the most part. >The REAL benifit of EISA comes into play when a multitasking system is being >used. When a UNIX task requests a block from the disk (on an ISA bus), the >CPU goes off and grabs that block-- it takes 100% of the CPU time to get that >block since the ISA bus and hard drive controllers are brain-dead. Actually, if you use a bus master on the ISA bus, this makes what you just stated untrue. I'll get into more detail at the end. >When an EISA based UNIX system requests a disk block, the OS tells the >controller to read a block into memory. It then puts that task on hold >(until the block is read in), meanwhile it goes off and runs another task. >So, while the one task is waiting for the disk controller, others are still >being executed-- where as an ISA based machine will pause all tasks since the >CPU is tied up doing the disk transfer. If a bus master is used in either EISA or ISA based buses, they both get a lot more free CPU time, but while the adapters/controllers are bus masters the CPU is dead. The gain comes from the speed the bus masters can move the data to/from host memory. Much faster than a PIO controller which requires the CPU's full attention. Thus with the bus master nmoving the data faster the CPU can get back to work quicker which represents an overall gain in throughput for the CPU. >MS-DOS cannot take advantage of this, since MS-DOS is not multi-tasking. In >fact, things like Desqview and Windows also cannot do this, since they are >built on MS-DOS's file system. The file system is irrelevant. But the rest of what you say is quite true. The reason they are single-threaded (Windows, Desqview) is due to the BIOS restrictions. In order to work with the hardware in a transparent manner, these programs use the INT13 BIOS calls for disk stuff. The INT13 BIOS is a single-threaded non-re-entrant piece of code that must be run in real mode. The operating system itself is designed to be a synchronous operating system where any read/write will be waited on before control is returned to the application. >Putting RAM on the EISA bus is silly, I agree. The EISA bus, like other >busses, should only be used for I/O. I/O, however, is more important when >you are using a 20 MIPS CPU. As well as an OS that can take advantage of it. Roy Neese Adaptec Senior SCSI Applications Engineer UUCP @ neese@adaptex uunet!cs.utexas.edu!utacfd!merch!adaptex!neese
david@kessner.denver.co.us (David Kessner) (06/18/91)
In article <1991Jun17.230100.6934@rand.org> edhall@rand.org (Ed Hall) writes: >In article <1991Jun11.062033.5218@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: >>The REAL benifit of EISA comes into play when a multitasking system is being >>used. When a UNIX task requests a block from the disk (on an ISA bus), the >>CPU goes off and grabs that block-- it takes 100% of the CPU time to get that >>block since the ISA bus and hard drive controllers are brain-dead. > >No, *some* ISA controllers are brain-dead. Not all. Ok, let me rephrase that: The restrictions that the ISA bus places on the hard drive controller makes the combination not-so-optimal. >>When an EISA based UNIX system requests a disk block, the OS tells the >>controller to read a block into memory. It then puts that task on hold >>(until the block is read in), meanwhile it goes off and runs another task. >>So, while the one task is waiting for the disk controller, others are still >>being executed-- where as an ISA based machine will pause all tasks since the >>CPU is tied up doing the disk transfer. > >Not with a bus-mastering controller. Most popular in the UNIX world >is the Adaptec 1540-series SCSI controller. This type of controller >will grab the bus and run it at full speed while the CPU goes off and >does other things. It can easily transfer data at the fastest speeds >SCSI can deliver. Bus mastering controller on an ISA bus, sure. In fact, what we all call bus mastering most comptuers call DMA. The problem is that DMA on the ISA bus is minimal at best (they are not as robust as other implamentations of DMA). In the context of ISA/EISA/MCA, the term "Bus Mastering" usually refers to the better DMA ability of the EISA/MCA bus and does not apply to the ISA bus. There is some question if DMA can go on WHILE the CPU is working. There is no real clear cut answer to this. On a 286/8 the CPU will stop during DMA, since the ISA bus and the RAM bus are the same, and the DMA will saturate the bus thus making the 286 wait. On a well designed 386/486 the ISA bus and the RAM bus are independant, and DMA from one to the other should only take up 10-30% of the RAM bus's time leaving a signifigant amount of time for the CPU. If this were the case, then your statement, above, would be correct. However, there is nothing to say that clone makers will make the board in this fashon. It is common thinking that most cleap clones only let the CPU crawl at a fraction of their original pace if not stop all together. At best, this is implamentation dependant, and something that works with one system may not be true in another. EISA, on the other hand, will ALWAYS leave the CPU running at a decent rate-- that's in the specification. Assuming that it is the case, a simple read/write to something on the ISA bus will STOP the CPU until DMA is completed. Let's say that the drive is DMA'ing and the CPU is computing. For some reason the seral card causes an intterupt (perhapse it got a character), and the CPU then tries to access the serial card but is forced to wait because DMA is chiewing up the bus. EISA fixes this by cutting down on the time the controller is on the bus (it transfers it's data in short burts rather than a continous stream that ISA's bandwidth imposes). > -Ed Hall > edhall@rand.org -- David Kessner - david@kessner.denver.co.us | 1135 Fairfax, Denver CO 80220 (303) 377-1801 (p.m.) | Reunite PANGEA! Compuserve? Isn't that some sort of FIDO BBS? |
markb@unix386.Convergent.COM (Mark Beyer) (06/19/91)
Me: >>If your TCP stack just can't pump data down to the bus adapter >>fast enough or, more likely, it can't receive it fast enough, maybe you're >>OK with the (cheaper ?) ISA interface. neese@adaptx1.UUCP writes: >Using the 32 bit EISA bus and bus mastering, the >ethernet card would utilize less of the bus I/O time, therefore allowing >more time for other I/O (such as disk) to occur. But the ISA can do bus mastering already. It's not the best implementation, but it works in at least some environments. >So many have looked at the EISA implementation from the perspective of, "WOW, >now I can move data at 33MBytes/sec!" Well, this isn't very pratical given >the current state of I/O adapters/controllers and the peripherals that exist >today (and for some time on the future). WRT hardware, I agree that you shouldn't consider just the EISA burst rate, and there's certainly a lot of work to do with ethernet adapters, too. But I still think the major bottleneck is performance in the implementation of the protocol stacks. People have made progress, but there's a ways to go yet. > But with that speed and a proper >buffering implementation on the adapter/controller, more I/O's can be >generated per slot than could ever be done on the ISA architecture. Maybe true of disk I/O. I was just speculating about network protocol stacks. -- Mark Beyer markb@convergent.com {uunet,sun,decwrl,hplabs}!pyramid!ctnews!markb