TCP/IP terminal concentrators
Barry Shein
Besides the Bridge TCP/IP terminal concentrators you might want to
compare the Annex made by Encore Computers (Something, Mass.)
I don't know much about the Bridge, I hear they are good, we got
involved with the Annex when we got an Encore/MultiMax. The Annex has
16-ports, uses either rlogin or telnet, can listen to rwho packets
(is that right? I'm pretty sure) to build its own host table or you
can just set things up yourself. It requires software on a host to
download it (it's written in C, we ported it to a SUN/3 in about
30 minutes, should work on any reasonable 4.2 system, they've already
ported it to a number of systems, I think all we had to do was fix
a minor portability glitch for them which they took back.)
They also have some project that should be available soon to front-end
to GNU Emacs in the Annex box, ask them.
-Barry Shein, Boston University
Disclaimer: if I worked for Encore I probably wouldn't spend all this
time in news :-)
Phil Ngai
>
>Besides the Bridge TCP/IP terminal concentrators you might want to
>compare the Annex made by Encore Computers (Something, Mass.)
>I don't know much about the Bridge, I hear they are good,
Having used both extensively, I recommend the Annex.
>The Annex has
>16-ports, uses either rlogin or telnet, can listen to rwho packets
>(is that right? I'm pretty sure) to build its own host table or you
>can just set things up yourself.
Yes, the Annex does seem to understand rwho. It can build a host table
and I assume rwho is how it does it. The Annex also listens to routed
for sites like us who have more than one internet router to remote
networks. The Bridge CS100 does not have printer ports, rlogin, rwho,
or routed.
>It requires software on a host to
>download it (it's written in C, we ported it to a SUN/3 in about
>30 minutes, should work on any reasonable 4.2 system, they've already
>ported it to a number of systems
This is an advantage. Much better than running around updating forty
or fifty floppies like the CS100 requires. (We don't have Ethernet
terminal servers in large scale use but when we do we'll have that
many to maintain.)
--
Bring back The Phone Company!
Phil Ngai +1 408 749 5720
UUCP: {ucbvax,decwrl,ihnp4,allegra}!amdcad!phil
ARPA: amdcad!ph...@decwrl.dec.com
kr...@diku.uucp
>In article <8...@bu-cs.UUCP> b...@bu-cs.UUCP (Barry Shein) writes:
.
. Various comments on Annex
.
>>It [Annex] requires software on a host to
>>download it (it's written in C, we ported it to a SUN/3 in about
>>30 minutes, should work on any reasonable 4.2 system, they've already
>>ported it to a number of systems
>This is an advantage. Much better than running around updating forty
>or fifty floppies like the CS100 requires. (We don't have Ethernet
>terminal servers in large scale use but when we do we'll have that
>many to maintain.)
If you have non diskbased cs100 with a NCS150 control server, you will
only need one copy of the software for cs100's or cs1's on the
network.
But still, you have little control over booting a box, and it would be
nice to have the Bridge boxes to try various boot servers on failure,
like the primary and secondary nameserver method.
--
--------------------------------------------------------------------------
Lars Povlsen, diku!krus/diku!postmaster
Institute of Datalogy, University of Copenhagen
--------------------------------------------------------------------------
Phil Ngai
>In article <12...@amdcad.UUCP> ph...@amdcad.UUCP writes:
>>This is an advantage. Much better than running around updating forty
>>or fifty floppies like the CS100 requires. (We don't have Ethernet
>>terminal servers in large scale use but when we do we'll have that
>>many to maintain.)
>
>If you have non diskbased cs100 with a NCS150 control server, you will
>only need one copy of the software for cs100's or cs1's on the
>network.
We have multiple Unix boxes which can make perfectly good boot
servers. Why should I buy a proprietary solution like an NCS150 when
Encore supplies free boot server source code? And don't forget you're
not just buying one NCS150, you have to buy two for each site if you
don't want all your terminal servers down when the NCS150 is down.
(The NCS150 is used for name service and boot service, I think?)
There is also a limit on the order of 20 to 40 terminal servers an
NCS150 can serve based on the amount of configuration information
stored on their little floppy.
>But still, you have little control over booting a box, and it would be
>nice to have the Bridge boxes to try various boot servers on failure,
>like the primary and secondary nameserver method.
The Annex sends out a broadcast boot request so you can have an
arbitrary number of boot servers.
Bridge Comm boxes are a closed architecture and proprietary, like IBM
MVS/VTAM/CICS. The Annex is open and allows you to use any Unix box as
a boot server. The Annex conforms to standards, like full TCP/IP with
ICMP echo, 802.3 style Ethernet transceiver connectors, 4.2 BSD rlogin,
RIP and rwho (BCI boxes have none of this). Choose what you want.
(ask me about how Bridge Comm violates the 802.3 AUI cable connector
spec, causing AUI connections to be unreliable.)
(I thought about comparing BCI to System V, but at least System V
is like Unix. I think BCI is more like MVS.)
--
The US Army uses 22 caliber size bullets in their assault rifles (M-16).
mich...@hplabsc.uucp
>
> Besides the Bridge TCP/IP terminal concentrators you might want to
> compare the Annex made by Encore Computers (Something, Mass.)
I have noticed in the discussion of tcp/ip terminal concentrators that
a new company called cisco Systems has not been mentioned. Their box, ASM
has 32 lines for $8K which is cheaper per port than Bridge or Encore.
It is a diskless system which can be configured manually or via some
server(s) on the network. It uses standard arpa protocols to accomplish
its configuration ( ie: bootp, RARP, tftp, domain name server, IEN-116 name ).
It will also have non-volatile RAM so that once configured it will not
depend on a server in the event of a power loss.
The disadvantage is that it doesn't support things like rwho or gnu-emacs
like the Encore. I haven't had an Encore in here to test so I can't comment
on its merits. I have tested both a CS/1 and CS/100 and found them to be
not all that great. I'm not crazy about Bridge's command language, the
maximum packet size on the CS/100 is a pain, and they tend to do strange things
like send out bogus arp replys.
cisco Systems is located in Menlo Park CA.
- Robert (michaels@hplabs)
Martin Schoffstall
I see no problems, but it truely is a garage-shop operation, how
many full time employees do they have? (< 5).
--
marty schoffstall
schoff%rpics.csnet@csnet-relay ARPA
schoff@rpics CSNET
seismo!rpics!schoff UUCP
martin_sc...@TROY.NY.USA.NA.EARTH.SOL UNIVERSENET
RPI
Computer Science Department
Troy, NY 12180
(518) 271-2654
Lars Povlsen
>In article <25...@diku.UUCP> kr...@diku.UUCP (Lars Povlsen) writes:
>>In article <12...@amdcad.UUCP> ph...@amdcad.UUCP writes:
>>>This is an advantage. Much better than running around updating forty
>>>or fifty floppies like the CS100 requires. (We don't have Ethernet
>>>terminal servers in large scale use but when we do we'll have that
>>>many to maintain.)
>>
>>If you have non diskbased cs100 with a NCS150 control server, you will
>>only need one copy of the software for cs100's or cs1's on the
>>network.
>We have multiple Unix boxes which can make perfectly good boot
>servers. Why should I buy a proprietary solution like an NCS150 when
>Encore supplies free boot server source code? And don't forget you're
>not just buying one NCS150, you have to buy two for each site if you
>don't want all your terminal servers down when the NCS150 is down.
>(The NCS150 is used for name service and boot service, I think?)
Yes, its used for both, but they will be down anyway, since the
doubled service only applies to the nameserver, not software &
configuration info.
>(ask me about how Bridge Comm violates the 802.3 AUI cable connector
>spec, causing AUI connections to be unreliable.)
The connector is a tragedy, agreed, we had a lot of trouble, and
still has.
But since we were only aware of the connection to be unreliable,
not what being the cause, please follow this up.
I think its necessary to stress that I'm not trying to sell anybody
anything from BCI (other than 20 CS100's at certain bad days ;-).
In fact, I would probably believe *anybody* saying they had a better
box than the CS100 and related products.
I was just commenting on the boot service that IS available.
I am sad to say I haven't any knowledge of the Annex. From what I hear
in this forum this is clearly a handicap.
Robert Michaels
> I see no problems, but it truely is a garage-shop operation, how
> many full time employees do they have? (< 5).
>
> --
> marty schoffstall
Yes, it should be pointed out that cisco is a startup company which I
believe currently has 8 full time employees. It is a spinoff from
Stanford University - just like SUN Microsystems.
robert michaels (michaels@hplabs)
Eric Lee Green
>> In article <8...@bu-cs.UUCP>, b...@bu-cs.UUCP (Barry Shein) writes:
>> I have noticed in the discussion of tcp/ip terminal concentrators that
>> a new company called cisco Systems has not been mentioned. Their box, ASM
>> has 32 lines for $8K which is cheaper per port than Bridge or Encore.
>>
>>
>> - Robert (michaels@hplabs)
>>
>People interested in CISCO should investigate the COMPANY. Technically
>I see no problems, but it truely is a garage-shop operation, how
>many full time employees do they have? (< 5).
>marty schoffstall
>seismo!rpics!schoff UUCP
Wow. This guy must not buy any computer besides IBM, because "Nobody
wants to buy anything from some LITTLE company, right?". It is
thinking such as this that stifles technical innovation.... you build
a better mousetrap, then nobody wants to buy it because you're not as
big as Imperial Business Machines.
In other words, I find it a disgusting attitude... though I'd want to
make darn sure that schematics and software source code could be
obtained in the event that the company failed.
{--
-- Computing from the Bayous, --
Eric Green {akgua,ut-sally}!usl!elg
(Snail Mail P.O. Box 92191, Lafayette, LA 70509)
Martin Schoffstall
> wants to buy anything from some LITTLE company, right?". It is
> thinking such as this that stifles technical innovation.... you build
> a better mousetrap, then nobody wants to buy it because you're not as
> big as Imperial Business Machines.
>
> In other words, I find it a disgusting attitude... though I'd want to
> make darn sure that schematics and software source code could be
> obtained in the event that the company failed.
> {--
> -- Computing from the Bayous, --
> Eric Green {akgua,ut-sally}!usl!elg
> (Snail Mail P.O. Box 92191, Lafayette, LA 70509)
What a foolish position. I believe that we own 3 IBM pc's. We own
things like Balance8000's, a 21000 and a few SUN's with serial
numbers under 100.
My posting was to allow people to have more of the story than
the "warm technological glow" that others posted.
Henry Schaffer
> make darn sure that schematics and software source code could be
> obtained in the event that the company failed.
> {--
> -- Computing from the Bayous, --
> Eric Green {akgua,ut-sally}!usl!elg
It turns out that this is not simple to do. A simple
escrow arrangement won't necessarily work. You need real good legal
advice if you want to count on obtaining schematics and source in
case of company failure. (The way it works is that the bankruptcy
trustee of the company sees this escrow of schematics and source as
an asset of the company and so can't let it go to you!)
--henry schaffer n c state univ
Phil Ngai
>>(ask me about how Bridge Comm violates the 802.3 AUI cable connector
>>spec, causing AUI connections to be unreliable.)
>The connector is a tragedy, agreed, we had a lot of trouble, and
>still has.
>But since we were only aware of the connection to be unreliable,
>not what being the cause, please follow this up.
This is pretty hard to describe in words but I will try. The best
explanation includes holding the products in your hands and pointing.
We have a backpanel with a hole cut in it and a DB-15 connector with
ears for mounting. Most people solder connectors into a PC board and
then attach a back panel in front of the connector. Let us imagine for
a moment that the back panel is not there. The head of a screw mounted
in the ears of the DB-15 will be a certain distance from the plane
made by the end of the DB-15. If you put a washer on the screw, that
will raise the head of the screw and bring it closer to the plane of
the connector end. Putting a back panel between the screw and the
connector ear has the same effect as a washer. The problem is that the
AUI cable has protruding screw heads so the DTE connector's slide
latch can engage with the AUI cable's screw heads. When you put the
equivalent of a washer on the DTE connector's screws they rise up and
interfere with the AUI cable's screws preventing the connectors from
fully engaging.
This is addressed by the IEEE 802.3 spec which requires "PANEL SHALL
BE FLUSH OR BEHIND CONNECTOR FLANGE FOR PROPER SLIDE LATCH OPERATION".
(see page 94 of the 802.3 spec) Mounting in front of the connector as
BCI does violates the spec and is unreliable.
I have looked at a lot of DEC products and they implement this properly
even when it required extra engineering to do so. I have brought this to
the attention of BCI and their response was that it was a pain to fix
and they weren't sure if they would bother.
No doubt customer feedback will help them decide whether or not
to fix this problem. It's unfortunate that the product couldn't have
been properly engineered in the first place and that they take (soon
to be if not already) international standards so lightly.
If this explanation is unclear please write to me and I will try to
clarify.
--
Classical music audiences are like ivory soap: 99 44/100 pure (white).
Phil Ngai
>In article <5...@rpics.uucp> sch...@rpics.UUCP writes:
>>People interested in CISCO should investigate the COMPANY. Technically
>>I see no problems, but it truely is a garage-shop operation, how
>>many full time employees do they have? (< 5).
>
>wants to buy anything from some LITTLE company, right?". It is
>thinking such as this that stifles technical innovation.... you build
>a better mousetrap, then nobody wants to buy it because you're not as
>big as Imperial Business Machines.
>
>In other words, I find it a disgusting attitude...
> Eric Green {akgua,ut-sally}!usl!elg
> (Snail Mail P.O. Box 92191, Lafayette, LA 70509)
I think information on the size of Cisco Systems is relevant and
here's why. When we install a service, people start using it and
depending on it to get their job done. Interruptions in service are
pretty serious because our customers depend on us to meet our
commitments just as we depend on our vendors to meet their
commitments. Unfortunately there is more to a product than great
engineering. There is manufacturing and support. All the icky boring
stuff that customers seem to demand in return for their money.
We had a very bad experience with one of our vendors. We had installed
about forty pieces of their networking equipment serving about 400
users when their equipment started failing. These were the worst kinds
of failures: in the field, intermittent, weeks or months after the
installation was completed. Our vendor recognized the seriousness of
this problem and started working on it. Eventually they isolated it to
a chip vendor which "from Jan 83 to Jun 84 delivered product which
exhibited separations or cracking of the metallization after about 500
hours of operation".
This was a big disaster for us and for our vendor. For 18 months our
vendor had been shipping booby trapped product. Of course, they went
back and yanked out all the bad chips, which must have cost them
greatly. It also cost us in downtime while finding the problem and
then while cleaning out the system. We're still not finished. How many
dollars and how many manhours? I estimate our vendor had to correct
the problem in thousands of boxes. Assigning a cost of $10 to $50 per
box, we're talking as much as $100,000. As for us, we had about a
dozen failures. Let's assume 10 engineers unable to work for a day
each time a failure occurs. 12 * 10 * 8 * $40 = $38,400. (no we don't
pay engineers $40/hour, that's the burdened cost) And that's just the
cost in payroll terms, the cost in lost sales is harder to estimate
but surely larger.
When a company reaches a certain size they have enough experience to
know things like the fact that buying from the lowest bidder is not
enough. Companies like HP have armies of reliability and qualification
engineers to prevent just this kind of disaster. HP, for example,
doesn't buy from just anyone who prints up a catalog. You have to
qualify to become a vendor for HP. This involves testing hundreds of
chips for weeks at a time, among other things.
This extra engineering is one ingredient that companies like mine look
for from their vendor, because the cost of failures are so high, and
one ingredient that a small company like Cisco is less likely to know
how to put in. I don't know much about Cisco, they may be a totally
together company but the odds are against it and Marty's comment about
their size is relevant.
Robert, just how well do you know the people at Cisco? Perhaps you
can address the issues I have raised in this article.
To say
>thinking such as this that stifles technical innovation.... you build
>a better mousetrap, then nobody wants to buy it because you're not as
>big as Imperial Business Machines.
shows a lack of knowledge about why companies buy products. Your
mousetrap may be more advanced technically but if you can't service it
like a bigger company can then I will have to consider the extra
(hidden) costs associated with such a product.
Eric Lee Green
>In article <8...@usl.UUCP> e...@usl.UUCP (Eric Lee Green) writes:
>>In article <5...@rpics.uucp> sch...@rpics.UUCP writes:
>>>People interested in CISCO should investigate the COMPANY. Technically
>>>I see no problems, but it truely is a garage-shop operation, how
>>>many full time employees do they have? (< 5).
>>
>>Wow. This guy must not buy any computer besides IBM, because "Nobody
>>wants to buy anything from some LITTLE company, right?". It is
>>thinking such as this that stifles technical innovation.... you build
>>a better mousetrap, then nobody wants to buy it because you're not as
>>big as Imperial Business Machines.
>>
>>In other words, I find it a disgusting attitude...
ferretting them out, because of poor quality assurance program. Then
brings up the example of HP, one of the few companies with a very
strict quality assurance program -- and high prices to match!
]
>To say
>
>>thinking such as this that stifles technical innovation.... you build
>>a better mousetrap, then nobody wants to buy it because you're not as
>>big as Imperial Business Machines.
>
>shows a lack of knowledge about why companies buy products. Your
>mousetrap may be more advanced technically but if you can't service it
>like a bigger company can then I will have to consider the extra
>(hidden) costs associated with such a product.
Yes, I would investigate Cisco, look at their quality control,
service, etc. However, I would do the same with any manufacturer,
regardless of size. Remember DEC's failing RA80s? and how DEC
continues to deny that there's any problem? It is not the size of the
company, but rather the service the company provides, which is at
issue.
Some small startups never make the transition needed between small
sales/small volume and large sales/large volume, i.e. setting up the
management infrastructure necessary. However, there's many examples of
companies that have a good product, that have the funds, that have the
service personel, who don't make it because they aren't "IBM
compatible" (if you're talking PCs) or "It's not a VAX" (if you're
talking super-minis) etc.
USL has three Pyramid 90x's, bought when Pyramid Technologies was a
small startup. They have provided good service in their intended duty.
If we had bought equivalent Vaxen of that era, they would have been
severely overloaded and slower than mollasses under a load of about 25
students average per computer. Should we have bought three Vaxen
because "Pyramid is just a little startup that could go out of
business tommorrow"?
Perhaps I'm confusing a university environment with a commercial
environment... when something breaks here, generally the answer is to
look around among us for an expert to fix it, rather than call in the
serviceman and wait for him to fly in from Massachusetts or
California. Do corporations lack this large body of talent? If so,
why? And if so, how do American corporations intend to compete with
Japanese corporations, which place great emphasis upon hiring talent
and conducting large amounts of research? Your average Japanese auto
executive started out assembling cars on the floor. If his car breaks,
he can fix it. The average American auto executive started out in
Harvard Business School. If his car breaks, he must call a mechanic.
Maybe that's why the Japanese build better cars!
In other words, I still find that people overlooking a company merely
because of its size is pretty nasty... but then again, as a proud
co-partner of a small telecommunications firm running out of a back
bedroom, I'd naturally think that :-). (our primary strategy is to
provide both a better program and better service than our big
competitor, which is sort of cocky and snaps at the users).
--
Henry Spencer
> service, etc. However, I would do the same with any manufacturer,
> regardless of size. Remember DEC's failing RA80s? and how DEC
Or ask that paragon of service and support, IBM, about the problems
with the PC/AT hard disks. "What problems?"
--
EDEC: Stupidly non-standard
brain-damaged incompatible Henry Spencer @ U of Toronto Zoology
proprietary protocol used. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
Robert Michaels
> > Yes, I would investigate Cisco, look at their quality control,
> > service, etc. However, I would do the same with any manufacturer,
> > regardless of size. Remember DEC's failing RA80s? and how DEC
> > continues to deny that there's any problem?...
>
Here is some info about the design and construction of the csico hardware:
The box is mulibus unit with a 9 slot card cage. All the sheet metal
including card cage are cisco designed and built. The power supply and
cooling blower are OEM.
The card cage contains a cpu card, ethernet card and 2 (16 line) terminal
interface cards. All but the ethernet interface card are desgined and
built by cisco. The ethernet card can be either interlan or 3Com.
The cpu card and terminal line cards are farily simple straight forward
design. As far as I can tell he uses no exotic ic's that couldn't be
replaced by a different vendor. The cpu consists of a 68000, 1 Mb of
RAM and room for 4 byte wide EPROMS. The terminal line card uses 8 2681s
which are fairly well known uarts.
I don't know who make the power supply. The blower is some German built
unit which apparently can move lots of air. It is quite noisy, but it
was designed for use in farily warm environments like wiring closets.
It is my opinion (for whatever its worth) that cisco hardware will not
have any significant problems. Their service attitude is they will send
you a new board if a problem occurs. I think that most corporations and
universities can live with that policy.
I have heard, although I'm not certain, that cisco has a farily flexible
policy regarding source code. I'm not sure what it is but it is supposed
to be possible for most customers to obtain a copy given the usual
restrictions.
- Robert Michaels ( michaels@hplabs )
DISCLAIMER: Please understand that these are my opinions and not that
of Hewlett-Packard Corporation.
Scott Brim
>I have heard, although I'm not certain, that cisco has a farily flexible
>policy regarding source code. I'm not sure what it is but it is supposed
>to be possible for most customers to obtain a copy given the usual
>restrictions.
At the end of June cisco told me they did not yet have a policy on
source availability, and they would have to talk to a lawyer about the
possibility of an escrow agreement, etc. We were talking about
gateways, not terminal servers.
------------------------------
Scott W. Brim s...@cu-arpa.cs.cornell.edu
Cornell Theory Center {decvax,ihnp4}!cornell!swb
265 Olin Hall bitnet: swb@crnlcs
Cornell University 607-255-9392
Ithaca, NY 14853
Phil Ngai
>Some small startups never make the transition needed between small
>sales/small volume and large sales/large volume, i.e. setting up the
>management infrastructure necessary. However, there's many examples of
>companies that have a good product, that have the funds, that have the
>service personel, who don't make it because they aren't "IBM
>compatible" (if you're talking PCs) or "It's not a VAX" (if you're
>talking super-minis) etc.
Well, I happen to believe the marketplace is where a product proves
how good it is. If it doesn't sell, then by definition it is not a
good product because it does not meet the needs of the customer. If a
customer wants to run Lotus and buys a PC instead of a Mac then the
Mac maker blew it in his market research.
>USL has three Pyramid 90x's, bought when Pyramid Technologies was a
>small startup. They have provided good service in their intended duty.
>If we had bought equivalent Vaxen of that era, they would have been
>severely overloaded and slower than mollasses under a load of about 25
>students average per computer. Should we have bought three Vaxen
>because "Pyramid is just a little startup that could go out of
>business tommorrow"?
It's nice that your decision worked out for you but if Pyramid had
failed I think you wouldn't have been so happy about it.
>Perhaps I'm confusing a university environment with a commercial
>environment... when something breaks here, generally the answer is to
>look around among us for an expert to fix it, rather than call in the
>serviceman and wait for him to fly in from Massachusetts or
>California. Do corporations lack this large body of talent?
First of all, we think the manufacturer should design it to reduce the
chance of it failing. Quality should be designed and manufactured in,
and I expect small companies to be less likely to have the expertise
to do this properly. Not that they can't, but that they are less
likely and therefore it is a valid question as to how large a vendor is.
As for fixing the machines we have better things to do than play field
service drone. Maybe if we had a large pool of slave labor (students)
we might do what you do. But if you had to pay for your manpower
perhaps you would do what we do.
>And if so, how do American corporations intend to compete with
>Japanese corporations, which place great emphasis upon hiring talent
>and conducting large amounts of research? Your average Japanese auto
>executive started out assembling cars on the floor. If his car breaks,
>he can fix it. The average American auto executive started out in
>Harvard Business School. If his car breaks, he must call a mechanic.
>Maybe that's why the Japanese build better cars!
Why should a semiconductor designer know how to fix a car? Or a computer?
>In other words, I still find that people overlooking a company merely
>because of its size is pretty nasty... but then again, as a proud
>co-partner of a small telecommunications firm running out of a back
>bedroom, I'd naturally think that :-). (our primary strategy is to
>provide both a better program and better service than our big
>competitor, which is sort of cocky and snaps at the users).
If you can't figure out what (rightful) disadvantages you have as a
small company, you may never become a big company. Stop complaining
the world isn't the way you want it and try to understand how it
really works.
I'd like to point out that we seem to be talking about two different
levels, software and hardware. It takes a lot of work to build high
quality hardware. Parts qualification is one thing I'm thinking of.
You have to test a large sample of each chip from each vendor. How
can a small company afford to buy a thousand 68020s just to bake them
in an oven and see how long they work?
Quality in software is a little different. If you burn enough midnight
oil you can probably produce as good a product as a big company.
Although I don't know if your manuals will be as good. Or if you will
offer training and system engineers to help customers. Maybe you can.
But that's the kind of thing big customers (you know, the kind with
lots of money) want.
--
Rain follows the plow.
Marc Kaufman
.>You have to test a large sample of each chip from each vendor. How
.>can a small company afford to buy a thousand 68020s just to bake them
.>in an oven and see how long they work?
Actually, you don't really need to do this. Just buy from the Japanese.
They actually test their parts before they ship them, unlike the
American companies.
Phil Ngai
>In article <12...@amdcad.UUCP> ph...@amdcad.UUCP (Phil Ngai) writes:
>>... Parts qualification is one thing I'm thinking of.
>
>Actually, you don't really need to do this. Just buy from the Japanese.
>They actually test their parts before they ship them, unlike the
>American companies.
You're wrong, some American companies do test their parts before
shipment. Also, I was specifically thinking of problems that only
show up after a few hundred hours of operation.