'386 Caching Motherboards
Terry Hull
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 (ka...@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.
--
From: ch...@vector.dallas.tx.us (Chip Rosenthal)
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.
----
From: convex!will...@uxc.cso.uiuc.edu (Bradley Williams)
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.
-------
From: pmafire!da...@uunet.UU.NET
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.......
------
From: voder!lynx!m...@apple.com (Mike McNally)
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.
------
From: j...@tiamat.fsc.com (Jim O'Connor)
Terry,
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 :-).
--------
From: ksuvax1!rutgers!att.att.com!twitch!rvk
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.
----
From: ficc!ka...@uunet.uu.net
Terry,
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.
-------
From: harvard!frog!ba...@gatech.edu (Chris Barr)
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
Hans Jespersen
>First though, I'd like to share something that was pointed out to my
>by Karl Denninger (ka...@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
hjesp...@trillium.waterloo.edu
uunet!watmath!trillium!hjespersen
Odyssey Research Associates
]...
]First though, I'd like to share something that was pointed out to my
]by Karl Denninger (ka...@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 ody...@unix.sri.com
Karl Denninger
>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 (ka...@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.
>
>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 (ka...@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"
Norman Kohn
>
>First though, I'd like to share something that was pointed out to my
>by Karl Denninger (ka...@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
karl lehenbauer
> 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.
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
-- ka...@ficc.uu.net console." -- Hitchhiker's Guide
Lars J Poulsen
>> 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 <36...@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 <la...@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 !!
Norman Kohn
>In article <36...@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
>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.
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.
Jonathan C. Broome
: 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.
---Jonathan Broome
jona...@ism780c.isc.com
Dick Dunn
[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.
Bruce A. McIntyre
> In article <36...@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.)
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.
John Pettitt
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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
John Pettitt
> In article <8...@anise.acc.com>, la...@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.
Daniel A. Glasser
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-----------
John Richardson
Subject: Re: '386 Caching Motherboards
Newsgroups: comp.unix.i386
Summary: re: caching and I/O boards
References: <6...@eecea.eece.ksu.edu> <2...@unix.SRI.COM>
In article <2...@unix.SRI.COM>, ody...@unix.SRI.COM (Odyssey Research Associates) writes:
> 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 (ka...@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 ody...@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.
JR
Hans Jespersen
>
>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 ?
Jon Bork
> In article <1989Jun27.0...@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.
>
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
John Pettitt
>In article <1989Jun27.0...@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.
>--
>Hans Jespersen
>hjesp...@trillium.waterloo.edu
>uunet!watmath!trillium!hjespersen
Piercarlo Grandi
hjesp...@trillium.waterloo.edu (Hans Jespersen) writes:
>In article <1989Jun27.0...@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.abe...@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
Brandon S. Allbery
+---------------
| In article <1989Jun27.0...@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 all...@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery ncoast!all...@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
Randall L. Smith
>> In article <1989Jun30.0...@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.
>>
> 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?
Cheers!
- randy
Usenet: ra...@rls.uucp
Bangpath: ...<backbone>!osu-cis!rls!randy
Internet: rls!ra...@tut.cis.ohio-state.edu
Alex Laney
> From article <15...@vail.ICO.ISC.COM>, by r...@ico.ISC.COM (Dick Dunn):
>
> 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.
>
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."
Jeff Tye
> 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
Peter Brouwer
>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.
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
Robert Bradbury
?
?:35I5I5555p@@@s:@ooo_1FzokR=zok9_R=#tDX9`RPP]] 1Fkx EB%Zo;
I55 k'66LlOXiRLW3 k|||`RP3(1FR<fffee*T k|z* k|z*Q*
lO &E ;;X X'Zb1?kkklO e txX/$*c>^*T)L8#*k '''h1?2
+pZ%ff*T4C 1`i*
XGGQ*bT4CE,MT4C bJpGG;;1/#E,3beT T TeTRLl6VVV(((;u(1;%%%
ne...@adaptex.uucp
>When I compare disk i/o rates in the better '386 unix systems (namely
>Interactive latest releases), I find better performance than systems
>that supposedly "do it right" (Sun, AT&T, etc?). I agree that the sys
>times are higher for '386 systems and that a nice bus master or shared
>memory controller would be an advantage. But compared to other
>systems, the current '386 controllers are only at a disadvantage if
>you have a lack of cpu.
But a nice bus master controller doesn't costs much more than the
standard controllers, so why even bother with the standard controllers?
Disk performance is one of the most important factors in putting together
a Unix system. I disagree 386 controllers are only a disadvantage if
you lack a cpu. (I take that to mean you are refering to the speed of
the CPU) The one thing that a faster CPU does for you is to help reduce
rotational latency hits due to the fact that commands can be executed
much faster, but even a faster CPU can't PIO data any faster than
a 16Mhz 386 so you still are giving up precious CPU cycles in a loaded
environment, when you do not have to.
Roy Neese
Adaptec Central Field Applications Engineer
UUCP @ {merch,texbell,killer}!cpe!adaptex!neese
Randall L. Smith
> The AT bus can do real world I/O at 5.3 Megabytes per second with out
> violating the spec. Some controllers will allow you to go faster, but the
> 8 Mhz AT timings have been violated.
No flames intended but who does the 5.3MB/sec.? That sounds pretty
phenominal and like a mathematical high water mark that is unattainable
in the real world because of other engineering problems/foul ups.
> The AT bus only offers good through put with a MASTER MODE controller.
> If you use the motherboard DMA controllers, things will CRAWL. Thats
> because they are 1978 3 Mhz 8080 type peripheral chips.
Who provides master mode or DMA controllers for the 386? Which Unix vendors
support these devices with the devices drivers. I'd be interested in
hearing of *any* cases, even if the controller vendor supplies the drivers.
Which vendors disks are supported with these controllers?
> The AT's main draw back is poor arbritration, it can not occur in parallel
> with a transfer and takes about 1.5 us. Once a block transfer starts, it
> can not go more than about 13 us, because the bus must be given back to
> REFRESH. (15 us max time)
>
>> I have a 16Mhz Intel 386 with WD1007-WA2 and the Maxtor 4380E on uport
Actually 4170E, but my fingers were over ambitious.:-)
>> 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.
>
> Your disk controller does not use DMA. The CPU does all the data movements.
> This is because it is an EXACT clone of the original PC-AT disk controller,
> which did not use DMA because the 80286 could move the data faster than the
> poor 3 Mhz motherboard controller. Master mode was not considered at the time.
>
> We use Compaq DESK-PROS running INFORMIX TURBO on our version of UNIX and
> it runs faster than a VAX 8200. (for real)
Thats fine, but the Vax 8200 is rated ~.9 MIPS. What are you running, a
33Mhz Compaq Deskpro? I'd guess thats around 4-5 MIPS. This is apples
to oranges. High performance SW to boot?! This discussion should not
entertaining a VAX vs. Intel war, but I have to argue this is an
inappropriate comparison.
Besides, if memory serves, the 8200 is a BI bus system supporting
(notably slow) Unibus adapters. The pronounced performance mismatch
between the 8200 CPU and BI bus were removed from Dec's lineup and
replaced with (the 8250) multiple parallel processors to balance the
system. Whether it helped or not is an acedemic question.
> We are using multiple parallel drives and it really cooks.
Multiple parallel drives is a spiffy way to enhance performance. That
gives SA's options for tuning and off loading hot disks.
> So the AT bus can be good for decent I/O provided its not asked to do
> double duty for being a main memory bus. (IE: Private 32 bit memory bus)
Perhaps, to summarize this whole discussion but the point to me is, who
realistically does these things. I ask that out of an interest in gaining
information not to stimulate debate.
Jonathan C. Broome
: Who provides master mode or DMA controllers for the 386?
The Adaptec AHA 1540 series of SCSI controllers use bus master mode with
onboard DMA controllers.
: Which Unix vendors
: support these devices with the devices drivers. I'd be interested in
: hearing of *any* cases, even if the controller vendor supplies the drivers.
386/ix supports the AHA1540 and 1542. According to other postings here, XENIX
also supports them.
: Which vendors disks are supported with these controllers?
Just about any normal SCSI disk you could want to use.
As far as performance goes, take a look at Jon Zeeff's recent posting of disk
benchmarks to see what the Adaptec controllers can do.
Jonathan Broome
jona...@ism780c.isc.com
ne...@adaptex.uucp
> SOME STUFF DELETED
>> If you use the motherboard DMA controllers, things will CRAWL. Thats
>> because they are 1978 3 Mhz 8080 type peripheral chips.
>
Adaptec and WD both supply bus master SCSI host adapters. Although, the
WD board can only support bus data transfers up to 5.7MBytes.sec and the
Adaptec (AHA-154x) can support bus data transfers up to 10MBytes/sec.
>Which Unix vendors support these devices with the devices drivers?
>I'd be interested in hearing of *any* cases, even if the controller vendor
>supplies the drivers.
ISC and SCO both support the AHA-154x SCSI host adapter from Adaptec.
>Which vendors disks are supported with these controllers?
As far as the Adaptec board goes, I would make some recommendations as to
which devices you used for performance reasons, but I don't know of any SCSI
devices (hard drives) that won't work. I would suggest Quantum, CDC,
or Maxtor for the best performance.
Daniel A. Graifer
John> So the AT bus can be good for decent I/O provided its not asked to do
John> double duty for being a main memory bus. (IE: Private 32 bit memory bus)
Randy>Perhaps, to summarize this whole discussion but the point to me is, who
Randy>realistically does these things. I ask that out of an interest in gaining
I am not expert on this, but wasn't this the point of AST's FastRam/FastSlot
combination first introduced in their Premium '286 series? I thought that was
a separate zero wait state 32 bit memory bus. Are any of the other '386
machines so equipped?
On a related topic:
The documentation on this here Everex System 3000I (25Mhz '386) is pretty
useless. I know that there is some kind of non-AT bus, as it has two 32bit
expansion slots. I also know that the memory access cannot be less than 3
wait state, as there is a jumper in the machine for "memory speed" set for
"100ns": that's why there is a 64K ram cache. Is there anybody out there
who knows this box, and can teach me a little bit more about it's architecture?
On a another topic discussed in this thread:
The above machine has a Western Digital WD7000-FAST2 SCSI controller. The spec
sheet for this card says: 4Mhz Z80 channel controller, 8Mhz WD33C93 SBIC, 16
logical threads, 5.3 MByte/Sec host xfer, 2.0 MByte/Sec Synch (1.5 MByte/Sec
Asynch) SCSI xfer. The features list says "First-party high-speed
bus-mastering DMA data transfers", and "16-byte FIFO on AT bus".
Thanks in advance,
Dan
----
Daniel A. Graifer Franklin Capital Investments
uunet!fciva!dag 7900 Westpark Drive, Suite A130
(703)821-3244 McLean, VA 22102
William Davidsen
| 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?
Some of the monitoring tools I use include pstat and vmstat. I save
the output of "vmstat 15 5760" into a file and then run some analysis on
it. I can chart any of the things displayed vs time, using a few awk
scripts and gnuplot. What I usually check is idle cpu vs page fault
rate, etc, as well as peaks. I have smoothing and peak detecting
software for the data.
I look at the output is "pstat | grep s" to see if my files/inodes in
the kernel are correctly sized. I look at swaps and paging rate to see
if I have enough memory (or too much). I look at context switch rate to
see if there are annomalous conditions.
I also have traces on ethernet and uucp traffic, useful to assure me
that when the interrupts/sec goes > 2k it's just a few lines coming in
at 9600 on dumb serial cards.
I'm not sure what you want to monitor, but I'm pretty happy with my
ability to identify response problems before they become critical. Now
if I could always find the $ to solve them early...
Hope some of this has helped.
bill davidsen (davi...@crdos1.crd.GE.COM)
{uunet | philabs}!crdgw1!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me
Chris Lewis
>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?
There's two ways:
- Look at the documentation for swap(1M) (admin reference).
You'll probably have to issue something like:
/etc/swap -a <device> 0 <size of device in blocks>
somewhere in one of the rc's to add the swap area. This would
allow you to have two (or more) swap areas active.
DO NOT GET THE SIZE WRONG - you may clobber other partitions.
[Eg: note the "WARNING" in the manual page - it doesn't check
overlap. We did. Fortunately before we loaded the other partitions
on the new disk ... whew!]
At least in ISC 1.0.6 386/ix do *not* try to delete a swap area.
The kernel will panic instantly.
- To simply move the swap from one partition to another, you have
to root around in the "system.*" files, change swapdev, and
rebuild the kernel. (/etc/atconf/systems/system.<whatever> in
ISC). You'll also want to mknod /dev/swap to be the major/minor
of the new swap area.
Deficiency: in ISC 1.0.6, ps (and other /dev/[k]mem peekers) don't
know how to handle two swap areas, so processes in the "other" swap area
won't show their uprocs. ("ps" looks in /dev/swap by default, and doesn't
appear to have any provision for looking in more than one anyways)
--
Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc.
UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis
Phone: (416)-595-5425
Peter Brouwer
>In article <4...@ssp2.idca.tds.philips.nl> p...@idca.tds.PHILIPS.nl (Peter Brouwer) writes:
>>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?
>
> - To simply move the swap from one partition to another, you have
> to root around in the "system.*" files, change swapdev, and
> rebuild the kernel. (/etc/atconf/systems/system.<whatever> in
> ISC). You'll also want to mknod /dev/swap to be the major/minor
> of the new swap area.
a message swapadd failed.
So what else has to be changed? I did not change the /dev/swap because I wanted
to keep the option to boot from the old kernel. Might this give any problems.
If only utilities like ps use /dev/swap I don't see any problems for the kernel
John Richardson
> In article <15...@frog.UUCP>, j...@frog.UUCP (John Richardson) writes:
> > The AT bus can do real world I/O at 5.3 Megabytes per second with out
> > violating the spec. Some controllers will allow you to go faster, but the
> > 8 Mhz AT timings have been violated.
>
> No flames intended but who does the 5.3MB/sec.? That sounds pretty
> phenominal and like a mathematical high water mark that is unattainable
> in the real world because of other engineering problems/foul ups.
>
refresh. The only problem is that the CPU can not get to memory during this
time. On cache systems like the Compaq, the CPU will run until a cache miss.
> > The AT bus only offers good through put with a MASTER MODE controller.
> > If you use the motherboard DMA controllers, things will CRAWL. Thats
> > because they are 1978 3 Mhz 8080 type peripheral chips.
>
> Who provides master mode or DMA controllers for the 386? Which Unix vendors
> support these devices with the devices drivers. I'd be interested in
> hearing of *any* cases, even if the controller vendor supplies the drivers.
> Which vendors disks are supported with these controllers?
>
Western Digital WD-7000 SCSI
Adaptec AHA-154[0,2] SCSI
AOX Master/386 (co-processor)
> .... about being faster than a VAX running data base
> Thats fine, but the Vax 8200 is rated ~.9 MIPS. What are you running, a
> 33Mhz Compaq Deskpro? I'd guess thats around 4-5 MIPS. This is apples
> to oranges. High performance SW to boot?! This discussion should not
> entertaining a VAX vs. Intel war, but I have to argue this is an
> inappropriate comparison.
>
Well it is appropiate, because a VAX to run a given load of a data base
application we are targeting costs about $500K with memory and disks,
and the system made from a 33Mhz 386 costs us about $20K including disks and
memory.
> Besides, if memory serves, the 8200 is a BI bus system supporting
> (notably slow) Unibus adapters. The pronounced performance mismatch
> between the 8200 CPU and BI bus were removed from Dec's lineup and
> replaced with (the 8250) multiple parallel processors to balance the
> system. Whether it helped or not is an acedemic question.
>
> > We are using multiple parallel drives and it really cooks.
>
> Multiple parallel drives is a spiffy way to enhance performance. That
> gives SA's options for tuning and off loading hot disks.
>
Its one of the ways we balance the fast 386 against the slow 3-1/2" drives.
> > So the AT bus can be good for decent I/O provided its not asked to do
> > double duty for being a main memory bus. (IE: Private 32 bit memory bus)
>
> Perhaps, to summarize this whole discussion but the point to me is, who
> realistically does these things. I ask that out of an interest in gaining
> information not to stimulate debate.
>
We will be anouncing a product October 1st that does these things with
386 PC hardware, AT bus, and SCSI controllers that outperforms a 500K computer.
(We have run the tests, and the numbers are real)
JR
John Richardson
Can this controller boot tape? If I have a custom BIOS that allows me
to specify the TAPE LUN for booting will it work?
The issue is that a SCSI IDENTIFY command must be done to determine that
the LUN is a sequential access device. Then a new READ/SPACE command format
must be used to access data blocks on the tape. I am going to end up having
to write a ROM driver in my BIOS (based on ANA-BOOKS AT BIOSKIT) so that
I can boot an ARCHIVE VIPER 1/4" tape. This is because the machine will have
no floppy, and we need to boot the tape to load the hard drive.
Any one from Adaptec out there???
JR
ne...@adaptex.uucp
The SCSI host adapter as it presently is configured can not boot from a tape
drive. This is of course a firmware issue. There is nothing to prevent it
from booting from a tape, except the lack of the software to do it with.
Lars J Poulsen
long and very interesting account of attempts at tuning his 386 Unix
system and then writes:
> (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!).
The Qbus is actually FASTER than the UNIBUS. At least a MicroVAX-II Qbus
is significantly faster than a VAX-11/785 UNIBUS. An IMPLEMENTATION of a
bus is usually much slower than the DESIGN of that same bus. And a
poorly specified bus may end up having the characteristics of the first
implementation cast in silicon in the controllers available for it, as
the controller designers try to work around design flaws.
The problem with the AT bus' performance seems to be that the original
implementation had a slow memory which did not leave enough bandwidth
for DMA peripherals after the processor got its memory accesses in. This
together with cost pressures led to a general tendency to optimize for
cost and single-user performance. This encourages dumb controller cards
with a sector buffer in a FIFO and controller-to-memory transfer by
programmed I/O.
In this situation, the best you can do is probably to have a single
drive, a controller with a large buffer, and a device driver with a
large cache and overlapped seek. The memory management should be
optimized for as little paging I/O as possible; you might be better off
with no paging and strict segment swapping (ever wonder why System V was
so slow to pick up paged memory management ?).
/ Lars Poulsen <la...@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 !!
John Richardson
>
> > Can this controller boot tape? If I have a custom BIOS that allows me
> >to specify the TAPE LUN for booting will it work?
> > The issue is that a SCSI IDENTIFY command must be done to determine that
> >the LUN is a sequential access device. Then a new READ/SPACE command format
> >must be used to access data blocks on the tape. I am going to end up having
> >to write a ROM driver in my BIOS (based on ANA-BOOKS AT BIOSKIT) so that
> >I can boot an ARCHIVE VIPER 1/4" tape. This is because the machine will have
> >no floppy, and we need to boot the tape to load the hard drive.
> >
> >Any one from Adaptec out there???
>
> The SCSI host adapter as it presently is configured can not boot from a tape
> drive. This is of course a firmware issue. There is nothing to prevent it
> from booting from a tape, except the lack of the software to do it with.
>
>
I am going to have to re-write the ROMS that come with this board in the
next couple of weeks just to get this feature. The problem is that ADAPTEC
refuses to license the ROM code, so I am going to have to clone the ROM.
JR
Chris Lewis
>In article <1989Jul13....@eci386.uucp> cle...@eci386.UUCP (Chris Lewis) writes:
>[ option one deleted ]
>> - To simply move the swap from one partition to another, you have
>> to root around in the "system.*" files, change swapdev, and
>> rebuild the kernel. (/etc/atconf/systems/system.<whatever> in
>> ISC). You'll also want to mknod /dev/swap to be the major/minor
>> of the new swap area.
>As described above this is what I did. The system comes up an panics. With
>a message swapadd failed.
>So what else has to be changed? I did not change the /dev/swap because I wanted
>to keep the option to boot from the old kernel. Might this give any problems.
>If only utilities like ps use /dev/swap I don't see any problems for the kernel
1) You don't need the swapadd if you only have one swap area. Changing swapdev
in the kernel *moves* the swap from one device to another. Swapadd is
only to be used when you want *two* swap areas, and is used somewhere
in the rc's to add the *second* one. Chances are your panic is simply
because you were trying to "swapadd" the same swap area that was already
set by swapdev, or you gave it bad parameters.
2) the kernel doesn't care what /dev/swap is - this is only for programs
like ps and crash. If you want to be able to boot from an older kernel
with the old swap, just make sure that you don't reuse the old swap
area as a filesystem - the kernel knows which swap area to use as the
*first* one from the swapdev variable.
If you want to be able to use "ps", you have to mknod /dev/swap as
the *existing* swap.
In other words, /dev/swap should be set to the "swapdev" device.
The kernel doesn't care what /dev/swap is, only swapdev. You can
boot any kernel, as long as swapdev points at a reasonable partition.
Fred Rump from home
->In article <1989Jun27.0...@specialix.co.uk> j...@specialix.co.uk (John Pettitt) writes:
->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 ?
While we have several 32 user systems out there based upon 16MB 15MhZ boxes
without cache but with Corollary smart cards, we don't have 32 terminals
attached as of yet. Users wanted the ability to add as needed without further
hardware modifications. Without having all the facts at hand I believe 16 to
20 terminals is the most actually installed. Of these I would suspect that
they are used only as needed for relatively short durations. I.E. folks are not
sitting there hacking away at their terminals all day. But the convenience of
having the terminal at the desk is the key ingredient that makes it all so
worth while.
Without having done any real benchmarks 8 to 10 people seem to have negligible
degradation. That also seems to be the limit of what our users require in the
small business marketplace.
Most 386 boxes leave here configured for 8 users. There have never been any
speed complaints.
Fred
--
This is my house. My castle will get started right after I finish with news.
26 Warren St. uucp: ...{bpa dsinc uunet}!cdin-1!icdi10!fr
Beverly, NJ 08010 domain: fr...@cdin-1.uu.net or icdi10!f...@cdin-1.uu.net
609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schiller
Jonathan Patrick Leech
>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...
Only if you *like* waiting 5 minutes for "hello.c" to compile, or
several seconds for screen updates (at 4800 baud, yet). We had a 780
as the main student machine at Caltech some years back, and it could
not comfortably handle more than 10-15 users or so.
--
Jon Leech (le...@apple.com)
Apple Integrated Systems
__@/
Michael Miller
>In article <14...@watdragon.waterloo.edu> hjesp...@trillium.waterloo.edu (Hans Jespersen) writes:
>->In article <1989Jun27.0...@specialix.co.uk> j...@specialix.co.uk (John Pettitt) writes:
>->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 ?
>While we have several 32 user systems out there based upon 16MB 15MhZ boxes
>without cache but with Corollary smart cards, we don't have 32 terminals
>attached as of yet.
I know of one commercially available (or soon to be) multi processor (386's)
backplane available. It has 32 meg (plus) memory available, copious amounts
of disk (something like up to 2.1 GB) and many other features. I know it
is AT compatible. I have seen it run 16+ users reasonably and reliably using
various desktop packages and doing some compilations of source. This was a
while ago tho and they may have gotten more performance out of it since
then. I don't know what os it runs currently. They did use specially
designed hardware to support the multiprocessing part of the architecture.
The system has something like 128 serial ports (I doubt concurrently,
but for sporadic users). I have seen it run 64 users (up to about 16+ at
any one time) do quite a bit of desktop work and printing in about 90 mins.
Actually, it has more than 128 serial ports but a conflict in the device
driver for those ports only permitted 128 ports for terminal usage. This
may have been resolved by now.
Just to make sure people know where I am coming from, I used to work for
this purposely unmentioned computer vendor. I was part of this;
I worked on the part of the project that got these benchmark results.
--
==========================================================
Michael Miller Key Systems Engineering Corp.
uunet!keysec!mike 4404 Cavalcade Ct.
1-301-731-7310 Burtonsville, MD. 20866
Piercarlo Grandi
In article <32...@apple.Apple.COM> le...@Apple.COM (Jonathan
Patrick Leech) writes:
Between comfortable use at the 10-15 users level and at the two dozen
user level there is a world of difference, i.e. suitable configuration
(always assuming that no large jobs are run, e.g. tex/lisp/gnu
etc...).
Using the 10% rule, with 10-15 users one is likely to see maybe 1-2
processes active at one time, with two dozen it is more likely 2-3; not
a terribly big difference.
The real difference TO RESPONSE TIME lies in the io configuration. If
you have a single disc, or a single data path to peripherals, a lot of
full screen edits with dumb (i.e. silo/fifo less) serial lines, too
little buffers, then a 780 is on its knees even before the 10-15 users
mark.
Adding a second disc, raising the buffer cache to 20-25% of memory
(e.g. 1-2 megabytes), enabling pseudo dma or installing intelligent
serial lines, having /tmp not on the same disc where users file are,
and swap/paging on the disc not where the root and /usr are, make a big
big difference. If you have independent data paths for your discs (e.g.
a MASSBUS one and a UNIBUS ones) things get that much better (using 4.3
instead of 4.2 and 4.2 instead of 4.1 of course improves things
again).
The same is true, with adjustments, on a 386. A 386 with one 300 meg
drive is MUCH slower than one with two 150 meg ones, preferably on a
multithreaded controller (e.g. AHA154x) or on two single threaded
controllers, especially if the disc partitioning is done ok.
On a 386 it is also important to ensure that there is enough
real memory that swapping never occurs, even if this means a
huge (huge!) waste of the commodity, as the system V swap
algorithms is badly, badly brain damaged (in particular
expansion swaps), even if paging ought to alleviate the
occurence of the problems.
With many users, cpu times are not that important, or at least not as
important as I/O (especially to temporary files and swap) latency and
overhead.
Too bad that the default configurations of almost all commercial
systems are badly detuned (notably SUN's, by the way). I have
seen many a UNIX system or network (not to speak of MVS, VMS,
EXEC, etc...) running at a fraction of their potential load
because of obviously poor tuning.
There is a problem also that many UNIX algorithms are simply
unsuitable for today's large machines; one famous case is the
beautiful BSD's `clock' page replacement algorithm, that was
carefully designed for performance, ON A 512K SYSTEM (the
original ucbvax). Too bad that on a machine with several
megabytes the `clock' sweep may now take *minutes*, thus making
it essentially useless... Similar is the case of the system V
swap algorithm, as already noted.
~XT6510300~Frank McGee~C23~L25~6326~
>The same is true, with adjustments, on a 386. A 386 with one 300 meg
>drive is MUCH slower than one with two 150 meg ones, preferably on a
>multithreaded controller (e.g. AHA154x) or on two single threaded
>controllers, especially if the disc partitioning is done ok.
There are some cases where a single large drive will perform better
than two smaller ones. A lot of controllers out there in PC-AT land
are not as smart as many of us would like. For instance, the Western
Digital 1007-WAH controller has a 16K track buffer on it. If you have
one disk, it helps with performance. If you have two disks,
performance gets worse because it can't use the track buffer as much
as with a single disk (it has to be flushed before it can read/write
to the other disk). With this particular controller, one 300 MB is
better than two 150's.
If you have multiple controllers or SCSI your statement would be very
true though.
Frank McGee, AT&T
Tier 3 Indirect Channel Sales Support
attmail!fmcgee
--
Frank McGee, AT&T
Tier 3 Indirect Channel Sales Support
attmail!fmcgee
John Richardson
> In article <3...@icdi10.UUCP> f...@icdi10.UUCP (Fred Rump from home) writes:
> >In article <14...@watdragon.waterloo.edu> hjesp...@trillium.waterloo.edu (Hans Jespersen) writes:
> >->In article <1989Jun27.0...@specialix.co.uk> j...@specialix.co.uk (John Pettitt) writes:
> >->Perhaps a better question is "How many 30+ user 386 systems do you
> >->know that run (period)."
> >->
>
> backplane available. It has 32 meg (plus) memory available, copious amounts
> of disk (something like up to 2.1 GB) and many other features. I know it
> is AT compatible. I have seen it run 16+ users reasonably and reliably using
> various desktop packages and doing some compilations of source. This was a
> while ago tho and they may have gotten more performance out of it since
> then. I don't know what os it runs currently. They did use specially
> designed hardware to support the multiprocessing part of the architecture.
>
> The system has something like 128 serial ports (I doubt concurrently,
> but for sporadic users). I have seen it run 64 users (up to about 16+ at
> any one time) do quite a bit of desktop work and printing in about 90 mins.
> Actually, it has more than 128 serial ports but a conflict in the device
> driver for those ports only permitted 128 ports for terminal usage. This
> may have been resolved by now.
>
> Just to make sure people know where I am coming from, I used to work for
> this purposely unmentioned computer vendor. I was part of this;
> I worked on the part of the project that got these benchmark results.
> --
> ==========================================================
> Michael Miller Key Systems Engineering Corp.
> uunet!keysec!mike 4404 Cavalcade Ct.
> 1-301-731-7310 Burtonsville, MD. 20866
I'd be ***REAL*** interested in any such machines. I have a multi-processor
UNIX OS that I have ported to the '386 AT systems, and I can not use its
multi-processor features until one of these machines come out. We are building
an OLTP product using 33 MHZ 386 motherboards, and want to upgrade to
multi-processor as soon as I can get hardware from someone.
JR