[comp.unix.i386] ALR CPU's

mel@fleet.UUCP (mel) (09/07/89)

Does anyone have any experience with ALR (Advanced Logic Research) CPU's
running Xenix.  I see that they have received favorable reviews in some
of the popular PC magazines but all tests were related to "DOS".

As an secondary point, has anyone run any benchmarks under Xenix 386 to see
if there are significant "throughput" differences on "equivalent" CPU's
running at either 20 mhrtz, 25mhrtz or 33 mhrtz.  Ideally these "tests"
should be run with multiple users on line "simulating" real input and output
under "real world" conditions.

Mel Shear
504-733-5333

dave@rylos.UUCP (David Mutterer) (09/09/89)

In article <29@fleet.UUCP>, mel@fleet.UUCP (mel) writes:
> Does anyone have any experience with ALR (Advanced Logic Research) CPU's
> running Xenix.  I see that they have received favorable reviews in some
> of the popular PC magazines but all tests were related to "DOS".

My experience with ALR's has been all bad..... we have three of them and
unless you're running very vanilla software, there is a 50/50 chance 
on whether it will run...  I even went as far as sending them back for
engineering upgrades on the motherboards..   but that didn't help.
Maybe I just bought them at a bad time (Jan-Jul '88) ..  I personally
don't see why you should "PAY THE PRICE" when there are so many good
"nonames" that use very good motherboards (like Wedge Tech)... 


						- David Mutterer (n2idf)
						{rutgers!}rylos!dave

jiii@visdc.UUCP (John E Van Deusen III) (09/12/89)

In article <193@rylos.UUCP> dave@rylos.UUCP (David Mutterer) writes:
> I personally don't see why you should "PAY THE PRICE" when there are
> so many good "nonames" that use very good motherboards (like Wedge
> Tech)... 
>
>						- David Mutterer (n2idf)
>						{rutgers!}rylos!dave

I think a lot of people who follow this news group would prefer to
integrate their own 386 PC UNIX systems instead of paying ALR, etc. to
do it.  Could we possibly develop a concensus as to which are the best
motherboards within various performance ranges?  Probably not, but in
an attempt to get the ball rolling:

	In the 25 MH, cache memory, AT-compatible range is anything
	better AND/OR cheaper than the AMI 25MH available from Jameco
	for $1999.95 (JE3027)?

	In the 33 MH no-holds-barred AT-compatible range, is anything
	better AND/OR cheaper than the ... I'm not sure I want to know.

It is really only possible to make a comparison for boards that are
available to everybody in quantity one.  Please don't say Intel unless
you know of a quantity-one supplier with a real price for an actual
model number.
--
     "... a 680 in Computer Science is not equivalent to a 680 in
     mathematics." -- 1989-90 GRE Information Bulletin

John E Van Deusen III, PO Box 9283, Boise, ID  83707, (208) 343-1865

uunet!visdc!jiii

NU013809@NDSUVM1.BITNET (Greg Wettstein) (09/12/89)

This article is being composed from an ALR 386/220 running XENIX 2.3.1.
Actually as you can tell from the mail header the mail is not coming from my
machine here but rather I am in a terminal emulator running under VPIX
connected to a mainframe.

I spent about two months trying to get XENIX up and running on the ALR and
I hope these comments will be of use.

I started out and installed 2.3.1 on a stock 386/220 with a 70MB micropolis
drive and 2 meg of ram on the motherboard.  Everything installed just fine
and ran like it was supposed to including VPIX.  Two meg of memory is somewhat
limited so I purchased the 32 bit memory expansion system which allows the
machine to be expanded to 6 meg (2 on motherboard, 4 on expansion).  On this
machine the memory expansion system consists of two identical boards which
plug into two special 16 bits slots which are designated as 32 bit expansion
slots.  Evidently the CPU and memory controllers know how to go through the
necessary gymnastics to gain 32 bit accesses to these boards.  I stuck the
boards into the machine, re-configured the CMOS and kicked up the operating
system.  XENIX came up, I did a ps -e and the kernel panicked.  I worked on
the machine for about two days, RTFM'ed extensively, tested memory with
various DOS utilities to no avail, the system still panicked.

I called ALR, described the system and was put through eventually to customer
support, (my local dealer is helpful but with no knowledge whatsoever of
things beyond DOS and some LAN stuff).  It should be noted that ALR is not
real eager to put just common folk through to their techie types, it took
some polite, forceful complaining to indicate to the people that there was no
competent local help available.

Their technical person was very knowledgable about the machine but offered what
I considered to be somewhat odd advice.  I had 80 nanosecond ram on the MB and
the expansion boards had a mix of 80 and 70 nanosecond ram on it.  The support
person immediately indicated that my problem was due to the mis-matched speed
of the chips on the expansion chassis.  I have stuffed a lot of boards in the
last five years and have had trouble with adding chips slower than indicated
but never trouble with faster chips.  I decided that they must know what they
are doing and replaced all the 70 nanosecond parts with 80's and fired things
up, kernel still panics.......

I got ahold of technical support and convinced them that the mix of 70 and 80
second parts was not it.  He then made the off-hand remark that they had some
reports of trouble with the memory expansion cards.  So I called my vendor,
he shipped me two new sets of boards with new memory which he had also put in
a 386/220 and run for a weekend with no problems.  Installed new boards,
kernel still panics.....

At this point I began figuring that there was a fatal flaw somewhere with the
motherboard and the addressing of the 32 bit memory on the expansion chassis.
The other thing that bothered me was that the CPU had a large heat sink
firmly cemented to the top of the chip.  The 386/220 I had was of about 1988
vintage when 20 MHZ machines were first starting to appear.  The thought kept
running through my mind, 'I wonder if they stuck 16 MHZ parts in these early
machines and over-clocked them.......'.  What was especially troubling was
that the heat-sink kept me from learning very much about the processor.

At this point I had spent about two months monkeying around and our project
was hopelessly behind schedule.  We put a lot of pressure on our local vendor
and he came up with a brand new 386/220.  This was just a box with a MB, no
memory, boards etc.  I transplanted everything out of my machine into the new
machine, kicked up XENIX and .....  no problems, everything including VPIX
ran flawlessly and has continued to run flawlessly 24 hours/day since that
time (2 months).

Since we had purchased the machine less than a year ago our dealer to his
credit left the new chassis with us and took back my old machine.  The last I
heard he was negotiating with ALR about a replacement motherboard.  From what
I understood ALR did not want to warranty the board since although the machine
was in use for less than a year our dealer had taken delivery on the machine
about two months prior to the time he had sold it to us and ALR claimed that
the machine was effectively out of warranty.  I guess that issue belongs in
the realm of dealyer <-> supplier negotiations.

The story does not end at this point however.  I learned from my dealer's
technical support person that they spent a lot of time dealing with ALR's
technical support department about this motherboard.  At some time during the
process it was acknowledged that some (perhaps early board runs) MB's had
severe DMA problems which produced problems with XENIX and/or NOVELL
applications.  It would have been nice if the technical support people had
bothered to tell me this the first time I contacted them.....  As it turns out
there is probably a pretty good chance that the first set of memory boards were
probably not troublesome although our vendor did have some difficulties with a
few of those boards.

I guess the upshot of all this is that our ALR 386/220 in its present
incantation effectively and efficiently runs XENIX.  It was unfortunate that it
took about 2 1/2 months to get to that point.  It is also interesting to note
that the CPU on my new motherboard does not have a heat sink cemented to the
top of the chip and the chip proudly proclaims itself as an 80386-20........

I should also point out that SCO technical support was very helpful throughout
the process.  They ran through all the hoops verifying that I did not have a
bad version of the kernel or of VPIX.  Considering that it was a total
hardware problem I couldn't ask for much more.  I would also like to thank
Karl Denninger whom I met through the net for spending a fair amount of time
talking to me about the problem even though I did not purchase any of the
hardware or software from him.  I would also like to thank the net for
providing a forum where a lot of my problems get answered before I need to
call the companies who sometimes seem much less knowledgable than the net
gurus.

                                      As always,
                                      Dr. Greg Wettstein
                                      NU013809@NDSUVM1

P.S.: If I had to do it again what would I do??  Tough question, my group
      is committed to a number of XENIX installations.  Considering the
      multiplicity of MB's, display adapters, drive controllers etc I am not
      sure how you get systems that will definitely work.  I am beginning to
      think that the thing to do is to find a VAR or a dealer who specializes
      in XENIX/UNIX hardware and software and buy your system from them.  I
      am sure that those guys have probably spent a lot of time trying to
      piece stuff together that they know works.

sl@van-bc.UUCP (Stuart Lynne) (09/13/89)

In article <640@visdc.UUCP> jiii@visdc.UUCP (John E Van Deusen III) writes:
>In article <193@rylos.UUCP> dave@rylos.UUCP (David Mutterer) writes:
>
>	In the 25 MH, cache memory, AT-compatible range is anything
>	better AND/OR cheaper than the AMI 25MH available from Jameco
>	for $1999.95 (JE3027)?

If we're going to do this right we will need to have a series of standard
questions to be answered.

Is this wholesale or retail? How much memory? Is it a pushed 20Mhz machine
or does it really have 25Mhz parts? What is the memory interleaving like?
What size is it? How many eight bit slots? How many sixteen bit slots? How
much memory can you put on the mother board? How much memory can you put in
via thirty two bit slots? What is the cost per MB for extra memory? Does it
have any built in peripherals (keyboard,clock,serial,parallel,SCSI,floppy,
video)? What BIOS (Phoenix,AMI,other)? Has it been tested with SCO 2.3.2? 
ISC 3.2? SCO 3.2? What are it's power requirements? How much cache can be
added? Compatible mounting holes? ISA, EISA or MCA?

I'm sure there's more. Anyone want to take a stab at organizing a standard
survey form that people can use to evaluate 386 boards?

-- 
Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)

sc@qmet.UUCP (Steve Croft) (09/13/89)

In article <2777NU013809@NDSUVM1>, NU013809@NDSUVM1.BITNET (Greg Wettstein) writes:
>                                       ...The 386/220 I had was of about 1988
> vintage when 20 MHZ machines were first starting to appear.  The thought kept
> running through my mind, 'I wonder if they stuck 16 MHZ parts in these early
> machines and over-clocked them.......'.  What was especially troubling was
> that the heat-sink kept me from learning very much about the processor.

I bought a 386/2, an early 16-MHz box from ALR.  It had one of the early
386 chips with the "16-bit only" stamp.  The problem was, I didn't know
it contained the 16-bit version because ALR covered the CPU with
motherboard serial number stickers!!!  In fact, it looked like one
sticker didn't quite cover it, there were two stickers over the stamp!!
These are not easy to peel off, either (they crumble up instead of peel
off).

I had the same prob as Greg with the customer support... no real
hassles, just took awhile to get the proper CPU.  After getting through
to technical support and convincing them that I really, truly was
planning to run 32-bit software, they put me on a waiting list and,
about four months later, exchanged the part.  I don't see the reason for
the cover-up, since Intel was exchanging these parts with manufacturers
for no fee.  Just an indication of ALR strategies, I guess.

BACKGROUND:  In case somebody is unaware, when the 386 first came out,
there were some problems running 32-bit software.  Intel continued
releasing the part with "16-bit software only" stamped on them.

steve
-- 
******************************************************************************
*   I will COBOL no more, forever... *      Steve Croft, Qualimetrics, Inc.  *
*                                    *            (uunet!mmsac!qmet!sc)      *
******************************************************************************

jackv@turnkey.gryphon.COM (Jack F. Vogel) (09/17/89)

In article <803@qmet.UUCP> sc@qmet.UUCP (Steve Croft) writes:
>In article <2777NU013809@NDSUVM1>, NU013809@NDSUVM1.BITNET (Greg Wettstein) writes:

 [Greg speculates that the problem is a 16Mhz part goosed to 20 ]

>I bought a 386/2, an early 16-MHz box from ALR.  It had one of the early
>386 chips with the "16-bit only" stamp.  The problem was, I didn't know
>it contained the 16-bit version because ALR covered the CPU with
>motherboard serial number stickers!!!  In fact, it looked like one

While Greg's speculation was a real possibility for why the SCO kernel was
panicing on coming up, yours is not. If the CPU in the ALR was not a double
sigma chip ( the double sigma was a stamp on the chip meaning it did not
have the 32-bit bug ) the installation disk would detect this, inform you
and not install. This assumes, of course, that you were installing 386
Xenix.

I have heard of a number of cases where SCO could not be successfully run
on an ALR system. This, however was some time back and I have no idea on
their current boxes. I would certainly advise "try it before you buy it"!!
--
Jack F. Vogel			jackv@seas.ucla.edu
AIX Technical Support	              - or -
Locus Computing Corp.		jackv@ifs.umich.edu