I posted a request for experiences with '386 Mylex and Micronics motherboards, and I received several interesting replies, so I thought I'd forward the information to the net. I'd also like to thank the folks who took the time to share their knowledge.
First though, I'd like to share something that was pointed out to my by Karl Denninger (k...@ddsw1.mcs.com). He told me there was a problem with intellignet serial cards and Ethernet cards in cached machines. The cache controller intercepts the reads and writes destined for the intelligent board, and that causes the board to either behave eratically or not at all. After all, the cache controller does not expect the contents of "memory" to change by itself. This is only a problem with boards that use a memory window in high memory. If the board's address space is between 640K and 1 MB, the reads and writes will bypass the cache so the board will work. This information was confirmed by Greg Fox at DigiBoard.
No direct experience, but vector is based on the 20MHz Micronics motherboard. The only problem I've had is that the supplied (Phoenix) in-BIOS setup program is incompatible with my Everex EGA card. I need to boot DOS and use the disk-based SETUP program instead.
A while back, somebody posted some comparison numbers showing that the main memory cacheing is a win. Unfortunately, I didn't save the message and I don't recall who did it.
I have a Micronics 25Mhz board. I only run MSDOS at this time as I am a relative novice to the PC world. I find it runs OK and does use the cache quite well, although a 387 will make a bigger impact overall. I run an Adaptec AHA1542 for SCSI disk and normal floppy interface. This card runs the motherboard in "bus master" mode and has no problem. The 20Mhz 386 from Micronics will not. I got 4Mb of RAM and the 25Mhz board from a local outfit for $2250. Is this too high or am I missing something?
After all is does 7.6MIPS and 1835 MFLOPS and NI=21. A diag package comes with the board and allows the software to switch the board to 6Mhz, 8Mhz or 25Mhz. The cache is switchable from software or the "turbo" switch. Also included is a BIOS to RAM copy routine that will speed some things up. The CACHE is controlled by the Intel chip (80285?) and comes with a single bank of RAM, with sockets for more to run in "two way associative". See the 285 for more information. The 387 socket can support Weitek and has crystal and jumper to run async. I am still learning this stuff and have lots to learn. I have never been crazy about Intel processors or addressing, but I am learning.
Seems like about a month ago someone mentioned Mylex and did not say anything bad about it.
I have a Mylex, and it beats the pants off a non-cached machine; probably the only faster machines are the Dell and the Everex Step. While I'm running Microport 3.0e, I suspect that the the increased speed will still be there under Xenix (as far as I know, the only way to turn off the cache is in hardware). If you're really after overall speed, get either a 15MHz ESDI disk (CDC preferably) or a SCSI disk and controller; looks like the DPT controller is a winner as well, with lots of RAM on it. Not cheap, though.......
I've never seen the Micronics 25Mhz board, but after fooling with a 20Mhz system from them I don't have much faith in them. We noticed several compatibility problems with the backplane design. It's cache is smaller than that of the Mylex, and it makes a difference.
Cache has a big impact on performance. If you're bothering to buy a 25Mhz machine, it's worth it to get the extra benefit of the cache. In fact, I'd guess that a 20Mhz Mylex with a cache would come close in performance (certainly price/performance) to a 25Mhz machine without a cache.
The Micronics MB (20MHz) that came in my portable seems to be pretty good. The only weird thing is that the 32bit RAM board is in the second to last card position, instead of the last card position (away from the power supply) as I've seen in most others. Micronics has several memory board options, so be careful that you get the memory board that will give you the RAM expansion that you want.
AMI also has a 20MHz board available. I don't know the price, but I can get it for you when I'm back in my office.
Both the AMI and Micronics boards exhibit the "10 bits of I/O address decoding" behavior, which causes problems with some I/O boards (in particular, a Logitech bus mouse :-).
an economic problem you might have with a fast motherboard and no cache is that all your memory has to be fast. this is expensive if you have a large amount of memory. it might turn out that your overall cost is higher by not having a cache.
I have had two Mylex 16 Mhz motherboards running System V/3, each with 64 KB of 40 ns cache and 4 MB of on-board RAM, for over a year with no problems or complaints.
My system is largely I/O bound when it is really busy, based on reports by sar.
I don't know how much premium there is for 25 MHz systems; my boards were only $1000 each, albeit with a 4 for 1 trade of my 256 Kbit DRAM to the dealer for megabit DRAMs for the motherboard.
Anyway, they've been fine boards...thought you might like to know.
Both Mylex & Micronics have been eclipsed by AMI in the marketplace, i.e. system vendors who used their boards @ 16/20 MHz moved to AMI for 25/33 MHz.
Micronics uses a single crystal instead of a separate one for AT-compatible BUS (not CPU) speed at 8MHz. This causes problems running cards such as 3Com Ethernet at higher speeds: they won't work. The 25 MHz MAY not have this problem (e.g. divide by 3 = 8.3 MHz, vs. divide by 2 @ 20MHz = 10). Micronics memory is 'Compaq-compatible', which means soldered chips.
Mylex' memory cards may be Intel-compatible & use SIMM ram chips. Tandon uses Mylex in at least some systems.
-- Terry Hull Department of Electrical and Computer Engineering, Kansas State University Work: te...@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!terry Play: tah386!te...@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!tah386!terry
In article <6...@eecea.eece.ksu.edu> te...@eecea.eece.ksu.edu (Terry Hull) writes: >First though, I'd like to share something that was pointed out to my >by Karl Denninger (k...@ddsw1.mcs.com). He told me there was a >problem with intellignet serial cards and Ethernet cards in cached >machines. The cache controller intercepts the reads and writes >destined for the intelligent board, and that causes the board to >either behave eratically or not at all. After all, the cache >controller does not expect the contents of "memory" to change by >itself. This is only a problem with boards that use a memory window >in high memory. If the board's address space is between 640K and 1 >MB, the reads and writes will bypass the cache so the board will work. >This information was confirmed by Greg Fox at DigiBoard.
Of course 640K - 1024 K is non-cacheable, that's where the shadow RAM for the BIOS lives. It'd be pretty stupid to cache ROM ( unless of course you have a controller that is smart enough to understand that any data data written to these locations is invalid ). I don't know of any controllers that do this ( the 82385 certainly doesn't ). Unfortunately the intel 82385 is not software configurable. This means that you cannot change the uncacheable regions via software like you can on a Austek A38152 or via internal registers on a Chips and Technologies 82C307. These changes can only be made through external circuitry connected to one of the 82385s pins. Since the manufacturer has no idea where you're going to put your serial I/O cards, Ethernet, video , etc. in memory they have probably set the controller up to cache everything in the '386s 4GB address space except shadow RAM.
-- Hans Jespersen hjesper...@trillium.waterloo.edu uunet!watmath!trillium!hjespersen
In article <663> te...@eecea.eece.ksu.edu (Terry Hull) writes: ]... ]First though, I'd like to share something that was pointed out to my ]by Karl Denninger (k...@ddsw1.mcs.com). He told me there was a ]problem with intellignet serial cards and Ethernet cards in cached ]machines. The cache controller intercepts the reads and writes ]destined for the intelligent board, and that causes the board to ]either behave eratically or not at all. After all, the cache ]controller does not expect the contents of "memory" to change by ]itself. This is only a problem with boards that use a memory window ]in high memory. If the board's address space is between 640K and 1 ]MB, the reads and writes will bypass the cache so the board will work. ]This information was confirmed by Greg Fox at DigiBoard.
I need more information on this. I am assembling a Unix box that will use ethernet, and naturally I want a cache. So far as I know, all ethernet cards use a memory window as their interface. It seems pretty strange to place that window in low memory, I anticipate a lot of hassle from the Unix kernel for this configuration so I don't want to take that route.
Does this mean I have to give up on a cache?
Do all the '386 caches assume that there are no coprocessors changing memory, or are there some boards that do bus watching?
Sure would hate to run cacheless (on credit?) since the cost/performance for a cache is very good.
-- B< Brian Kahn unix.sri.com!orawest!brian odys...@unix.sri.com
In article <3...@ddsw1.MCS.COM> n...@ddsw1.MCS.COM (Norman Kohn) writes: >In article <6...@eecea.eece.ksu.edu> te...@eecea.eece.ksu.edu (Terry Hull) writes: >>I posted a request for experiences with '386 Mylex and Micronics >>motherboards, and I received several interesting replies...
>>First though, I'd like to share something that was pointed out to my >>by Karl Denninger (k...@ddsw1.mcs.com). He told me there was a >>problem with intellignet serial cards and Ethernet cards in cached >>machines. The cache controller intercepts the reads and writes >>destined for the intelligent board, and that causes the board to >>either behave eratically or not at all. After all, the cache >>controller does not expect the contents of "memory" to change by >>itself.
>Egad! And what do DigiBoard users do?? I'd just ordered a caching >motherboard... have to call Digiboard in the morning, I have two >of their smart boards in the intended host machine.
>It's an interesting trade: if you're I/O bound, use smart boards. >If you're CPU bound, get cache memory. I thought that come of these >cache boards did periodic write-throughs to memory (but why bother... >not that memory, like swap space, is there only to swap out the >cache when it gets full).
It all depends on which digiboard you are talking about.
The older COM8/is show up between 640K and 1MB; they are immune to most caching schemes, as most caches don't work between 640K and 1MB...
HOWEVER -- the new ones WILL NOT WORK IN MOST CACHE MACHINES. These boards are the ones with the outboard box (containing part of the circuitry); they show up in extended memory space, and WILL get hosed. Strangely enough, their software asks if you have a cache -- I called Digi and asked about this, and their response was that they have worked around it -- for the Compaq and Everex systems ONLY. They specifically said that most other cached machines will NOT work right -- and that they have no fix for it (how could they, when there are many ways to do caching......)
This is one of the reasons we shy away from cached boards -- there is no way to determine if a particular cache will interfere with a given smart peripheral (one where dual-ported memory is used).
The same problem will appear with any board that puts buffer memory in a dual-ported area above 1MB.... if you have such a board, and try to use it in a cached system, you are likely to find that it does not work (or at least doesn't work right).
We've complained to several manufacturers of motherboards about this -- and told them that if they want to sell us any of their product, we want to see a setup option (in CMOS) that allows us to disable caching above any specified point in memory. So far NOT ONE MANUFACTURER has indicated an interest in doing this.
Beware.......all these "cache vendors" appear to have DOSitis....
-- Karl Denninger (k...@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
In article <6...@eecea.eece.ksu.edu> te...@eecea.eece.ksu.edu (Terry Hull) writes: >I posted a request for experiences with '386 Mylex and Micronics >motherboards, and I received several interesting replies...
>First though, I'd like to share something that was pointed out to my >by Karl Denninger (k...@ddsw1.mcs.com). He told me there was a >problem with intellignet serial cards and Ethernet cards in cached >machines. The cache controller intercepts the reads and writes >destined for the intelligent board, and that causes the board to >either behave eratically or not at all. After all, the cache >controller does not expect the contents of "memory" to change by >itself.
Egad! And what do DigiBoard users do?? I'd just ordered a caching motherboard... have to call Digiboard in the morning, I have two of their smart boards in the intended host machine.
It's an interesting trade: if you're I/O bound, use smart boards. If you're CPU bound, get cache memory. I thought that come of these cache boards did periodic write-throughs to memory (but why bother... not that memory, like swap space, is there only to swap out the cache when it gets full). -- Norman Kohn | ...ddsw1!nvk Chicago, Il. | days/ans svc: (312) 650-6840 | eves: (312) 373-0564
In article <3...@ddsw1.MCS.COM>, n...@ddsw1.MCS.COM (Norman Kohn) writes: > Egad! And what do DigiBoard users do?? I'd just ordered a caching > motherboard... have to call Digiboard in the morning, I have two > of their smart boards in the intended host machine.
Trubba not. Mylex motherboard owners, at least, can order a replacement PAL from Mylex that prevents the cache from caching certain ranges of memory addresses. I got one that keeps it from caching the high two megabytes in the 16 meg physical address space. The result is that the Bell Tech ACE and Blit cards work. (or are supposed to, I don't have a Blit.) -- -- uunet!ficc!karl "Contemptuous lights flashed across the computer's -- k...@ficc.uu.net console." -- Hitchhiker's Guide
te...@eecea.eece.ksu.edu (Terry Hull) writes: >> .. there [is] a problem with intelligent serial cards and Ethernet >> cards in cached machines. The cache controller intercepts the reads >> and writes destined for the intelligent board, and that causes the >> board to either behave eratically or not at all. After all, the cache >> controller does not expect the contents of "memory" to change by >> itself. In article <3...@ddsw1.MCS.COM> n...@ddsw1.MCS.COM (Norman Kohn) writes: >It's an interesting trade: if you're I/O bound, use smart boards. >If you're CPU bound, get cache memory. I thought that come of these >cache boards did periodic write-throughs to memory (but why bother... >not that memory, like swap space, is there only to swap out the >cache when it gets full).
(1) Almost all caches use write-thru (i.e. block on a write just like on a read/miss. This makes the cache circuitry much simpler (It would create a bad scheduling problem if a cache miss on a read caused invalidation of a block that had not been flushed to memory yet).
(2) A few boards with memory-mapped registers do magic things when you READ a register. This confuses programmers, and is thus bad practise, but it positively does not work with a cache (or with some optimizing compilers :-). This is true for dumb card (used to be a problem with some third party stuff on PDP-11's).
(3) The big problem is with intelligent cards with data buffers in a dual-ported memory. Because the data going into the memory did not go over the main bus, the cache could not see it change and thus could not invalidate cached data from the same addresses. In such cases, the driver will have to flush the cache before looking in those buffers. Most caches have a mechanism for flushing the cache, thus forcing re-loads of all cached locations.
(4) Intelligent cards can help CPU-bound programs a lot, by moving the protocol-related CPU cycles out to the front-end processor. / Lars Poulsen <l...@salt.acc.com> (800) 222-7308 or (805) 963-9431 ext 358 ACC Customer Service Affiliation stated for identification only My employer probably would not agree if he knew what I said !!
In article <3...@ddsw1.MCS.COM> k...@ddsw1.MCS.COM (Karl Denninger) writes: >In article <3...@ddsw1.MCS.COM> n...@ddsw1.MCS.COM (Norman Kohn) writes: >>In article <6...@eecea.eece.ksu.edu> te...@eecea.eece.ksu.edu (Terry Hull) writes: >>>The cache controller intercepts the reads and writes >>>destined for the intelligent board... >The older COM8/is show up between 640K and 1MB; they are immune to most >caching schemes, as most caches don't work between 640K and 1MB... >HOWEVER -- the new ones WILL NOT WORK IN MOST CACHE MACHINES.
I called Digiboard and got much the same comment, though I was not told why and I'm not familiar with the /Xe (I run two Com/8i's).
I also discussed the problem with someone at DTK, and with AIS, a distributor that has installed DTK caching motherboards with Com/xi boards. All say that the boards work together. It may indeed by that the Digiboard manages to use an uncached part of the address space.
I think that the unix drivers for the Com/xi configure the dual-ported RAM as a large circular buffer. The buffer is larger than the cache, so the cache will always write through to the board before intercepting a new write to any board address. However, the driver will tell the i/o board to look in the buffer at a time when the buffer has not, in fact, been written to. The board looks at its own memory, not yet updated by the cache controller. Meanwhile, new data is still in the cache.
In article <3...@ddsw1.MCS.COM> k...@ddsw1.MCS.COM (Karl Denninger) writes:
: HOWEVER -- the new ones WILL NOT WORK IN MOST CACHE MACHINES. These boards : are the ones with the outboard box (containing part of the circuitry); they : show up in extended memory space, and WILL get hosed. Strangely enough, : their software asks if you have a cache -- I called Digi and asked about : this, and their response was that they have worked around it -- for the : Compaq and Everex systems ONLY. They specifically said that most other : cached machines will NOT work right -- and that they have no fix for it (how : could they, when there are many ways to do caching......)
I've found that a number of motherboard manufacturers DO provide a way around the cache if your code knows about it -- on Compaq, Dell, CSS, and quite a few other systems, set the A31 address bit (`or' in 0x80000000) when doing a memory access, and it will bypass the cache and access the correct memory location. I use this technique on several systems every day to avoid the cache intercepting accesses to a Bell Tech Blit video card.
In article <8...@anise.acc.com>, l...@salt.acc.com (Lars J Poulsen) writes: [stuff about recent discussion of memory on smart boards arguing with caches on 386]
> (4) Intelligent cards can help CPU-bound programs a lot, by moving the > protocol-related CPU cycles out to the front-end processor.
In theory, yes. In practice, they don't seem to help all that much.
Unless the interface to a smart board is very well designed, with at least a nod to what UNIX wants, it's not likely to do a lot of good. A good cache, on the other hand, is a dramatic improvement for a fast 386 for most problems...you're likely to get better network performance out of a cached machine with a dumb net board than an uncached machine with a smart one (because you increase the CPU speed by more than the added load). When you're not using the net, obviously the cache wins. -- Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 ...Lately it occurs to me what a long, strange trip it's been.
In article <4...@ficc.uu.net>, k...@ficc.uu.net (karl lehenbauer) writes: > In article <3...@ddsw1.MCS.COM>, n...@ddsw1.MCS.COM (Norman Kohn) writes: > > Egad! And what do DigiBoard users do?? I'd just ordered a caching > > motherboard... have to call Digiboard in the morning, I have two > > of their smart boards in the intended host machine. > Trubba not. Mylex motherboard owners, at least, can order a replacement PAL > from Mylex that prevents the cache from caching certain ranges of memory > addresses. I got one that keeps it from caching the high two megabytes in > the 16 meg physical address space. The result is that the Bell Tech ACE and > Blit cards work. (or are supposed to, I don't have a Blit.)
I also have the Mylex card, and while I could shut off Cache, why do it... Mylex (actually HEI, my supplier) sent me the PAL so I can install smart boards. I have since installed several of these machines, some with ARNET cards and some with COMPUTONE cards. I am happy with both versions, and the hardware runs like a scalded cat. My older 16mhz 386 systems run as fast as most 20 and some 25 mhz systems. The cache really makes a difference. I am going to install Ethernet this summer, so will pass on the results. bruce ========================================================================= Bruce A. McIntyre, McIntyre Designs, Inc. VOICE(215)322-1895 143 Bridgetown Pike, Langhorne, Pa. 19047 DATA (215)357-2915 {wells|lgnp1}!mdi386!bruce bruce@wells tbit+
Unix, Xenix, Netware and PC-DOS Applications development. Specializing in Database Applications since 1980.
After following the debate on what is and is not cached on 386 systems I would like to add my .02 pence worth.
Firstly a disclaimer: We make smart I/O cards so I have some strong views on how to design them.
If an I/O controller is memory mapped (like most ethernet and serial boards) the device driver code must have some way of either invalidating the cache befor reading the boards ram or telling the cache controller to ignore the board.
Invalidating the cache is bad for lots of reasons including: It hits performance in a big way and the code to ensure that all access are wraped in a cacheon / cacheoff pair is not simple - all interrupts must be disabled while cache is off to prevent the CPU leaving the driver while caching is still off.
The normal way to use cached systems is to locate the board in non-cached memory or find some way to tell the cache controller that the board is not to be cached.
There are 3 basic systems for doing this:
1) automatic mapping. Some systems, the intel 302 for example, will only cache 32 bit ram (I.E. motherboard ram and Intel expansion cards). This type of system is easy - you plug the card in and it works.
2) Windows. Some machines, the Olivetti XP[79] for example, have one or more address windows that are not cached. Normally these windows are from 0xA0000 to 0xFFFFF (640k to 1Mb) and sometimes in the last 1 meg.
3) Address faking. The third class of system, example Compaq, allows the card to be accessed at it's real address plus 2 Gigs. In other words if the physical address of the card has A31 true the card will be seen as non-cached at it's normal address.
Almost all serial cards will work in types 1 and 3, although if your system is new the card vendor may not yet have type 3 support in the driver. Type 2 systems can only support cards that live in the correct address ranges. This means that the card must have a small address window (64K or less) or it will not fit in the first meg.
In summary the ideal card will have a small memeory window and support lots (say 32) port from one card (I told you I had views on this - guess what our card takes and how many ports it has :-)
John Pettitt Technical Director Specialix International -- John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, U.K., KT7 0TR {backbone}!ukc!slxsys!jpp jpp%slx...@uunet.uu.net j...@specialix.co.uk Tel: +44-1-941-2564 Fax: +44-1-941-4098 Telex: 918110 SPECIX G
From article <15...@vail.ICO.ISC.COM>, by r...@ico.ISC.COM (Dick Dunn):
> In article <8...@anise.acc.com>, l...@salt.acc.com (Lars J Poulsen) writes: >> (4) Intelligent cards can help CPU-bound programs a lot, by moving the >> protocol-related CPU cycles out to the front-end processor.
> In theory, yes. In practice, they don't seem to help all that much.
> Unless the interface to a smart board is very well designed, with at least > a nod to what UNIX wants, it's not likely to do a lot of good. A good > cache, on the other hand, is a dramatic improvement for a fast 386 for most > problems...you're likely to get better network performance out of a cached > machine with a dumb net board than an uncached machine with a smart one > (because you increase the CPU speed by more than the added load). When > you're not using the net, obviously the cache wins.
I'm biased: We make serial cards.
Whilst I agree that a faster CPU is a good idea and that cache gives you a relativly cheap way of getting more speed, you have missed the point of smart I/O cards.
There are two reasons for having smart I/O cards:
1) Interrupts. The ???86 chips have a very large interrupt latency. On a dumb card you get one interrupt per byte send/received. As a result of this interrupt the line diciplin code gets called and an context switch _may_ occour (1 in sizeof(CLIST) times on transmit and 1 per char for a raw input application e.g. vi).
2) Protocol. Lots of _crap_ is talked by people who have put all editing stuff on the card. Yes the standard line disc code is brain dead it's some of the slowest code around. However it does not matter because if you are doing high speed input then 1 gets you 10 it's raw mode. The times when you are using icanon a fast typist may reach 5 CPS on a good day.
On the output side it is worth doing some of the basic output stuff on the comms card but _only_ because the code in the kernel is so bad. If this were not the case then how come I can do 16 lots of 38400 baud with opost done on a Z280 on a comms card but less the 4 if we force it back on the a 16Mhz 386 ?
How many 30+ user 386 systems do you know that run `dumb' cards ?
> -- > Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 > ...Lately it occurs to me what a long, strange trip it's been.
-- John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, U.K., KT7 0TR {backbone}!ukc!slxsys!jpp jpp%slx...@uunet.uu.net j...@specialix.co.uk Tel: +44-1-941-2564 Fax: +44-1-941-4098 Telex: 918110 SPECIX G
Many years ago in my unfortunate youth, I delt with an add-on cache/memory management unit on a DEC LSI-11/2 (which had none of its own) Q-Bus system. The cache hardware was smart enough not to cache I/O page references, but there was a frame buffer on this machine with several planes, each broken into chunks which were mapped, one at a time, through a single 8kb address window in physical memory. We were able to solve the cache vs. memory problems by flushing and disabling the cache unit from the driver code before each group of references, and turning it back on when done. This can be a performance hit, I realize, but may be a workaround until better solutions are found. I assume that there is a fairly standard set of ways to flush and turn the memory cache on and off on i386 systems. If a manufacturer develops a proprietary caching system, it ought to publish this information for their implementation. I suspect it is generally just an I/O reference. -- ___________________________________________________________________________ __ Daniel A. Glasser One of those things that goes uwvax!per2!dag "BUMP!!!(ouch)" in the night. ---Persoft, Inc.---------465 Science Drive-------Madison, WI 53711-----------
> In article <663> te...@eecea.eece.ksu.edu (Terry Hull) writes: > ]... > ]First though, I'd like to share something that was pointed out to my > ]by Karl Denninger (k...@ddsw1.mcs.com). He told me there was a > ]problem with intellignet serial cards and Ethernet cards in cached > ]machines. The cache controller intercepts the reads and writes > ]destined for the intelligent board, and that causes the board to > ]either behave eratically or not at all. After all, the cache > ]controller does not expect the contents of "memory" to change by > ]itself. This is only a problem with boards that use a memory window > ]in high memory. If the board's address space is between 640K and 1 > ]MB, the reads and writes will bypass the cache so the board will work. > ]This information was confirmed by Greg Fox at DigiBoard.
> I need more information on this. I am assembling a Unix box that will > use ethernet, and naturally I want a cache. So far as I know, all > ethernet cards use a memory window as their interface. It seems pretty > strange to place that window in low memory, I anticipate a lot of > hassle from the Unix kernel for this configuration so I don't want to > take that route.
> Does this mean I have to give up on a cache?
> Do all the '386 caches assume that there are no coprocessors changing > memory, or are there some boards that do bus watching?
> Sure would hate to run cacheless (on credit?) since the cost/performance > for a cache is very good.
> -- > B< Brian Kahn unix.sri.com!orawest!brian odys...@unix.sri.com
These are problems that had to be wrestled with in larger systems until small systems now have these issues, without any conventions. The problem is that most (if not all) motherboards do watch dog the memory cycles that occur on the AT (or U-channel) bus. If they did not, all of your DOS and UNIX software would have to execute a cache flush command when ever any I/O or context switching occured. This is because the new data in memory would not be seen if something was cached. This is a problem on the 68030 if you turn their caches on, because you have to modify the system to do this in order to use their non-watchdogged caches. Obviosly, standard MS-DOS and UNIX runs, so motherboard vendors must watchdog all I/O access to memory. The problem comes up with so called 'dual-port' memory, which is an I/O board that looks like memory to the system, but a microprocessor can change data in that memory without the benfit of an AT bus cycle. That way the watchdog never sees the memory cycle that changed that specific location. So the cache has stale data in it. The way around this problems is to not cache ALL accesses to the specific board. That way you always read the 'latest' data. The way this is supposed to be done was called out in the INTEL 80386 HARDWARE reference manual, and that is to reserve A31 of the CPU to be fed in the the NC (no-cache access) pin of the 80385, or other cache controller. This way you can specify any address and not have caching in the way. The Compaq follows this correct convention, and if other vendors do not, protest by not buying their products. If a convention as important as this is not adhered to (thats why INTEL published it in the book all motherboard designers have to read), we can have a really bad situation of what driver works with what motherboard for what peripheral.
NOTE TO MOTHERBOARD MAKERS:
The INTEL 80486 has a cache enable bit on a per page basis, while this is nice and the 80386 should have had it, but to be able to run drivers and operating system software meant for the 80386, you must still use the A31 convention. An OR gate will take care of this. If you have need for more than 2 gigabytes of physical memory, then there can be special consideration.
In article <1989Jun27.074031.11...@specialix.co.uk> j...@specialix.co.uk (John Pettitt) writes:
>How many 30+ user 386 systems do you know that run `dumb' cards ?
Perhaps a better question is "How many 30+ user 386 systems do you know that run (period)."
Apart from this reference I have seen/heard many people talking about putting 32 users on a '386 PC system. In my experience (although limited to 20 MHz, non-cached machines) it seems as though 32 is a unbelievably high number of users to put on a 386 system. The bus seems to be the bottleneck in most cases, specifically due to disk I/O. I know I'd feel much better proposing a 32 user mini based solution that a '386 based one.
How many CONCURRENT users ( of typical office automation software ) can you respectfully support on a '386 PC ? I know this is vauge and will vary considerably depending on the configuration but anyone want to give it a shot ?
-- Hans Jespersen hjesper...@trillium.waterloo.edu uunet!watmath!trillium!hjespersen
In article <14...@watdragon.waterloo.edu>, hjesper...@trillium.waterloo.edu (Hans Jespersen) writes: > In article <1989Jun27.074031.11...@specialix.co.uk> j...@specialix.co.uk (John Pettitt) writes:
> >How many 30+ user 386 systems do you know that run `dumb' cards ?
> Perhaps a better question is "How many 30+ user 386 systems do you > know that run (period)."
> Apart from this reference I have seen/heard many people talking about > putting 32 users on a '386 PC system. In my experience (although limited > to 20 MHz, non-cached machines) it seems as though 32 is a unbelievably > high number of users to put on a 386 system. The bus seems to be the > bottleneck in most cases, specifically due to disk I/O. I know I'd > feel much better proposing a 32 user mini based solution that a '386 based > one.
Both of you are asking the same question. The approach we took on the U6000/50 from Unisys is to design the system with a SCSI bus, a memory bus and a AT bus. Since the disk I/O is not only the AT bus and memory access is not on the AT bus, there is plenty of bandwidth for I/O cards and networking cards. Add a high-speed cache and a well-tuned UNIX and 32 users IS doable. (And oh by the way, you can outperform a 32 user mini like the NCR Tower, too).
How do you measure it? Well the same way everyone tries to, you run the available commercial benchmarks like AIM and NEAL/NELSON. That's where the honest user claims come from. Well, as honest as benchmarks can get. :-)
Let's not overlook the fact that given a good architecture, the 386 IS a minicomputer class chip.
-- Jon Bork Unisys Network Computing Group (408)-435-3679 j...@Convergent.COM -or- {pyramid, sri-unix, pacbell}!ctnews!jon
hjesper...@trillium.waterloo.edu (Hans Jespersen) writes: >In article <1989Jun27.074031.11...@specialix.co.uk> j...@specialix.co.uk (John Pettitt) writes: >>How many 30+ user 386 systems do you know that run `dumb' cards ? >Perhaps a better question is "How many 30+ user 386 systems do you >know that run (period)."
Quite a large number.
>Apart from this reference I have seen/heard many people talking about >putting 32 users on a '386 PC system. In my experience (although limited >to 20 MHz, non-cached machines) it seems as though 32 is a unbelievably >high number of users to put on a 386 system. The bus seems to be the >bottleneck in most cases, specifically due to disk I/O. I know I'd >feel much better proposing a 32 user mini based solution that a '386 based >one.
Firstly a 20 Mhz non-cached 386 is not the place to start building a 32 user system. Most of the big systems we see are based on 25 Mhz cached machines like the top end Olivetti machines.
Secondly a large number of these systems run DPT or SCSI disks, this gives a noticable improvment in performance. The AT bus is only used by these systems for I/O, memory has it's own bus so the throughput is not too bad.
Thirdly, most of the user of this type of system are running commercial accounting or office automation software. The system I am typing this from is a 25 Mhz Intel 302 and 4 engineers can kill it (well jeremyr kill it by running VP/ix), but the office automation is a very different application.
On the 32 terminal system there will be between 8 and 24 active users most of the time and of those only about half will be doing much more than reading mail / enquiry access.
>How many CONCURRENT users ( of typical office automation software ) >can you respectfully support on a '386 PC ? I know this is vauge and >will vary considerably depending on the configuration but anyone want >to give it a shot ?
This is the real point - CONCURRENT users - my guess is with a good disk an a good I/O board (like ours plug plug :-) and a well tuned system you should be able to support about 16-20 wp users or about 8-10 spread sheet users (need a 387 tho).
We have a number of customers with 32 and in one case 64 terminals on 386 systems and very usable perfomance levels.
Oh and I nearly forgot - you can _never_ have too much RAM.
In article <1989Jun30.075132.22...@specialix.co.uk> j...@specialix.co.uk (John Pettitt) writes:
hjesper...@trillium.waterloo.edu (Hans Jespersen) writes: >In article <1989Jun27.074031.11...@specialix.co.uk> j...@specialix.co.uk (John Pettitt) writes: >>How many 30+ user 386 systems do you know that run `dumb' cards ?
>Perhaps a better question is "How many 30+ user 386 systems do you >know that run (period)."
Quite a large number.
Agreed. In most light applications, i.e. o.a. or general timesharing, at any one time 1/10th of the users are running a process. A Vax 11/780, which is a much less powerful machine than a suitably configured 386, could easily run two dozen (and three dozen with some effort) users doing small compiles etc...
>Apart from this reference I have seen/heard many people talking about >putting 32 users on a '386 PC system. In my experience (although limited >to 20 MHz, non-cached machines) it seems as though 32 is a unbelievably >high number of users to put on a 386 system. The bus seems to be the >bottleneck in most cases, specifically due to disk I/O. I know I'd >feel much better proposing a 32 user mini based solution that a '386 based >one.
Firstly a 20 Mhz non-cached 386 is not the place to start building a 32 user system. Most of the big systems we see are based on 25 Mhz cached machines like the top end Olivetti machines.
Well the difference is not that great, after all. It's only CPU.
Secondly a large number of these systems run DPT or SCSI disks, this gives a noticable improvment in performance.
This is the point. I disagree with John Petitt on the benfits of a DPT controller, but I wholeheartedly recommend for timesharing ATs a multithreaded SCSI controller with TWO disks (never, never, never run a multiuser machine on a single disc), and with a suitable balancing of filesystems among the discs (rule #1: you want on the root disc the root+usr filesystems and the /tmp and /usr/spool filesystems, and on the other disc the user filsystems and the swapping/ paging area).
Two fast (under 25 ms average seek), balanced discs on a multithreading SCSI controller give an *immense* reduction in io wait (second best is to have two controller, one per disc, for ESDI or ST406/MFM/RLL ones that are not multithreaded).
The AT bus is *not* a bottleneck for i/o; it has a bit more bandwidth than the Unibus, and a lot more than io buses, and is *not* used for CPU/memory transactions.
Oh and I nearly forgot - you can _never_ have too much RAM.
Apart from thefact that the System V swapping/paging algorithm is badly designed, this is largely cured by having the swap not on the same disc as the binaries, and byt having multithreading disc controllers. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac...@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcvax!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: p...@cs.aber.ac.uk
As quoted from <14...@watdragon.waterloo.edu> by hjesper...@trillium.waterloo.edu (Hans Jespersen): +--------------- | In article <1989Jun27.074031.11...@specialix.co.uk> j...@specialix.co.uk (John Pettitt) writes: | >How many 30+ user 386 systems do you know that run `dumb' cards ? | | Perhaps a better question is "How many 30+ user 386 systems do you | know that run (period)."
> (...)
| How many CONCURRENT users ( of typical office automation software ) | can you respectfully support on a '386 PC ? I know this is vauge and | will vary considerably depending on the configuration but anyone want | to give it a shot ? +---------------
I'm glad you specified 386 PC. We have a client running on a 16MHz (!) 386 non-PC (system designed specifically for Unix, with a fast non-PC bus) with 30 users; it's not exactly a Cray, but a large part of their speed problems come from a badly-designed database application (Informix has a tendency to get *real* slow when you put a lot of reverse-video fields on a form) -- and it's faster than many 286'es I've used with only a few users on. And the system at our office (N.B.: no relation whasoever with ncoast) is 33 MHz, somewhat slower bus but faster than ISA, and commonly only two users -- but both typically have 6 MultiView windows open and cranking, for a total of 12+ effective users. It's hard to tell the difference between the 33MHz machine with that load and the 25MHz machine it replaced with only one user not running under MultiView.
Also consider that the Sequent Symmetry is 386-based -- and I've not noticed any speed problems on uunet even under a fairly heavy load. (Of course, the Symmetry is a multiprocessor architecture.)
I'd wait and see what EISA does for the situation before giving up on the 386. Bus speed and bandwidth seem to be the limiting factors, and they're being addressed (albeit slowly).
++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allb...@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allb...@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@<backbone> NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser
>In article <1...@aber-cs.UUCP>, p...@aber-cs.UUCP (Piercarlo Grandi) writes: >> In article <1989Jun30.075132.22...@specialix.co.uk> j...@specialix.co.uk (John Pettitt) writes: >> The AT bus is *not* a bottleneck for i/o; it has a bit more bandwidth than >> the Unibus, and a lot more than io buses, and is *not* used for CPU/memory >> transactions.
> Conclusions: To make standard UNIX Synergy assumptions with the AT > buss aint neccessarily so. There is a problem here. (I never knew > that the AT buss had more bandwidth than UNIBUS!, are you SURE of > this!!!) (LSI 11 buss, Q buss , I'll believe this one!).
I sincerely doubt the AT bus has more bandwidth than the Unibus. The Unibus, (from the processor handbook) has 2.5 million 16bit words/sec, maximum throughput. It seems to top out at 4.88MB/sec. Since its the theoretical high, actual milage will vary. To get actual benchmarks we end up digressing into interupt handling, arbitration, device latency, etc. I don't *think* the AT bus begins to approach this speed even with all other things being equal.
Since I couldn't find actual values for the AT, I'll hedge.:-) I recall someone relating 12-20 users on a Vax/780 crawling along. Lots of bad configuration problems could cause that, but not likely the Unibus itself. Too little memory and lots of terminal i/o could kill any Vax without a LAT board in a hurry.
I have a 16Mhz Intel 386 with WD1007-WA2 and the Maxtor 4380E on uport 3.0e. I can swamp the beastie by myself when things get cooking. Just get all the devices working and it slows to thrashing itself without progress.
Just what utilities are there to monitor Unix systems? Under all Dec OS's, there are a ton of active system monitoring/tuning tools available. I *have found* few active monitor tools with Unix. Sure ps, sar, sadp, profiler but what about buffer usage, cache hits, cache size changes, and other items in /etc/sysdef output? Is this in TFM? Where?
This is no doubt my own ignorance or is this another open market? sysviz and sysadm don't count. I'm corrupted by the Dec way of thinking. What are the good Unix tuning books around?
In article <1989Jun27.074031.11...@specialix.co.uk>, j...@specialix.co.uk (John Pettitt) writes: > From article <15...@vail.ICO.ISC.COM>, by r...@ico.ISC.COM (Dick Dunn):
> Whilst I agree that a faster CPU is a good idea and that cache gives > you a relativly cheap way of getting more speed, you have missed the > point of smart I/O cards.
> There are two reasons for having smart I/O cards:
> 1) Interrupts. The ???86 chips have a very large interrupt latency.
> 2) Protocol. Lots of _crap_ is talked by people who have put all
There's more:
3) System Load. If the system is single-user, then a dumb card is cheaper, and performance will be better. If it is multi-user, then overall performance will be better with the smart card. I think this means that you should always buy smart cards for UNIX/multi-user AT-clones.
4) Synchronous Usage. This is related to 1). If you have to respond in a finite real-time to a network, you can't be swapped out, never mind delayed.
I think that benchmarks are generally done with one user active, so they don't correspond to the reality of multi-user usage. Smart cards don't generally yet use 32-bit/high MHZ processors. You'll see more of this shortly. Then the scale will again tip to the smart cards.
-- Alex Laney, Xicom Technologies Corp., Ottawa, Canada (613) 728-9099 uunet!mitel!sce!xicom!alex (NOT alex@xicom) Fax: (613) 728-1134 "You save time, increase the amount of work done and it is easy."
In article <14...@watdragon.waterloo.edu>, hjesper...@trillium.waterloo.edu (Hans Jespersen) writes:
> How many CONCURRENT users ( of typical office automation software ) > can you respectfully support on a '386 PC ? I know this is vauge and > will vary considerably depending on the configuration but anyone want > to give it a shot ?
I have customers that support 30 users. How do they do it?
1) Lot's of memory. 16MB at least or if the BIOS supports it, more.
2) Intelligent I/O cards for serial ports. Try the Corollary 8X4 mux card or the SpecialX mux card. Both offer exceptional performance. Strive to balance the load amongst the cluster boxes. Use a mux card that *supports* CPU caching. And research your vendor before taking the plunge.
3) Above all else, install the DPT caching disk controller with 8MB or more of disk cache. It really works. Disk I/O is the biggest bottleneck in AT class machines.
4) Tune, tune, tune, that kernel. Layout your disk for optimum use. Give the OS plenty of swap space, don't be stingy.
That's how you do it. Take away the I/O burden of the CPU and the humble AT chassis can support that kind of load for OA and databases. CAD/CAM and robotics would be a different thing. Oh, and running DOS ala VP/ix and DOSmerge would subtract from the number of users as well. DOS is such a pig that it reminds me of some of our governments: take all and give back very little. :-) :-) :-) :-) :-)
-- Jeff Tye ncar!noao!asuvax!hrc!swusrgrp!jeff southwest!/usr/group is the Southwest U.S. chapter of /usr/group
In article <1...@aber-cs.UUCP> p...@cs.aber.ac.uk (Piercarlo Grandi) writes: >Apart from thefact that the System V swapping/paging algorithm is badly >designed, this is largely cured by having the swap not on the same disc as >the binaries, and byt having multithreading disc controllers.
How do you move the swap to an other disk. I am using V3.1 added a disk with the diskadd tool. This lets you create swap on the new disk. I have modified swapdev description in the systems file. ( Added 16 to the minor device number ). What else is there to do? Do I have to link /dev/swap to the new swap area before the reboot with the new kernel?
The manuals are not very clear it this point. -- # Peter Brouwer, ## # Philips TDS, Dept SSP-V2 ## voice +31 55 432523 # P.O. Box 245 ## UUCP address ..!mcvax!philapd!pb # 7300 AE Apeldoorn, The Netherlands ## Internet p...@idca.tds.philips.nl
