9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] Re: PC capability
@ 2000-05-05 14:38 Digby
  0 siblings, 0 replies; 4+ messages in thread
From: Digby @ 2000-05-05 14:38 UTC (permalink / raw)


> it no doubt depends on which workstations and PCs we've experienced.
>
> for instance, i would never choose SCSI as an example, because from the earliest
> days of my experiences with 386 PCs and above, the SCSI adapters i was able to use
> -- even ISA ones -- were fairly cheap, better documented, easier to handle
> (ie did more, and that sensibly), and much faster than the SCSI
> interfaces on equivalent Sun-3s and Sparcs, and even MIPS,
> that cost much more.

Yes, you can buy SCSI cards for PCs, but if you are talking about
ease of adding hardware, then the fact that with most PCs you have
to go out and buy a SCSI interface in order to add your third hard disk
or a tape drive, and with most other platforms that I have used since
the early 1980's (MAC, SUN, MVME1x7...) you get the SCSI on board,
makes the PC less easy in my books.

Once you have to add adapter cards, then you get into comparing DMA,
Interrupt and other bus structures, which have always been superior
on non-Intel machines. Up until recently, that has meant squeezing
the data through the very narrow hole that is ISA/EISA, the limitations
of which led to all those various alternate standards for plugging in
video adapters in an attempt to get reasonable performance.
Even now, with the different systems converging to PCI bus, you still
have all the arcane x86 baggage to deal with on PCs.

As I recall, when I did my first Unix install on a PC, the only acceptable
SCSI controller available was the Adaptec (1542 I think), at serveral
hundred dollars a go. The cheap alternatives had no real DMA capability,
and it was almost impossible to get documentation for them. If you
got any programming documentation included with your PC SCSI cards,
you were much luckier than I have ever been...

The Introl and Ciprico controllers I was using at the same time on
VME based systems came with full documentation, did DMA and
vectored interrupts properly, and handled disconnect/reconnect,
synchronous transfers and multiple initiators.

I agree with you that the PC plug in cards are usually cheaper.
But this is just a function of the PC market dominance forcing up
the price of alternatives by denying them economies of scale.

> IDE hasn't been that primitive for years.  indeed, probably the main complaint
> i'd make about PCs is that things sometimes change so often in various ways
> (ether, graphics, etc) that it's hard to keep up.   mind you, that was true
> in different ways with Sun and SGI.
>
> indeed, the most useful non-Intel platform i've used was the BeBox,
> because although it was PowerPC, it had ISA and PCI slots
> (and a useful NCR scsi chip) just like .... errr ... a PC.  it was
> dual-processor, though, long before the normal PC (but no secondary cache).

The PCI bus is being adopted by many systems more or less in parallel,
which just means that bus is ceasing to be a distinguishing factor
when comparing ease of adding hardware.

IDE is getting better (or at least less limitted), but it is still
far easier to add hardware using SCSI than IDE. The unfortunate
trend for other systems like BeBox and MBX to include IDE rather
than SCSI, which is technologically a backward step is, as far as
I can see, an unfortunate necessity in order to take advantage of
the lower price IDE disks that result from the higher volume sales.

Regards,
DigbyT
--
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk




^ permalink raw reply	[flat|nested] 4+ messages in thread

* [9fans] Re: PC capability
@ 2000-05-08  9:14 Jolt-Freak
  0 siblings, 0 replies; 4+ messages in thread
From: Jolt-Freak @ 2000-05-08  9:14 UTC (permalink / raw)


Problem is that in a world where money rules all the cheapest (and
often worse) things succed. I am still at school and out of everyone
in my year (around 150 people) only around 3 knew about other
operating systems. A fair amount think that windows is the only
operating system, and the same thing is true of hardware, the majority
do not even know that thier are computers other than *86 based
machines. I can see myself that it would be great for each system to
have scsi instead of ide but i can also see that these people do not
care, they just want a fast comptuer (fast meaning whatever the man in
the shop says is fast) and they want it as cheap as possible, IDE
disks are now almost as fast as scsi disks and they are so much
cheaper that manufactures have to use ide drives to simply compete.

Jolt-Freak




^ permalink raw reply	[flat|nested] 4+ messages in thread

* [9fans] Re: PC capability
@ 2000-05-05 14:10 Digby
  0 siblings, 0 replies; 4+ messages in thread
From: Digby @ 2000-05-05 14:10 UTC (permalink / raw)


> it no doubt depends on which workstations and PCs we've experienced.
>
> for instance, i would never choose SCSI as an example, because from the earliest
> days of my experiences with 386 PCs and above, the SCSI adapters i was able to use
> -- even ISA ones -- were fairly cheap, better documented, easier to handle
> (ie did more, and that sensibly), and much faster than the SCSI
> interfaces on equivalent Sun-3s and Sparcs, and even MIPS,
> that cost much more.

Yes, you can buy SCSI cards for PCs, but if you are talking about
ease of adding hardware, then the fact that with most PCs you have
to go out and buy a SCSI interface in order to add your third hard disk
or a tape drive, and with most other platforms that I have used since
the early 1980's (MAC, SUN, MVME1x7...) you get the SCSI on board,
makes the PC less easy in my books.

Once you have to add adapter cards, then you get into comparing DMA,
Interrupt and other bus structures, which have always been superior
on non-Intel machines. Up until recently, that has meant squeezing
the data through the very narrow hole that is ISA/EISA, the limitations
of which led to all those various alternate standards for plugging in
video adapters in an attempt to get reasonable performance.
Even now, with the different systems converging to PCI bus, you still
have all the arcane x86 baggage to deal with on PCs.

As I recall, when I did my first Unix install on a PC, the only acceptable
SCSI controller available was the Adaptec (1542 I think), at serveral
hundred dollars a go. The cheap alternatives had no real DMA capability,
and it was almost impossible to get documentation for them. If you
got any programming documentation included with your PC SCSI cards,
you were much luckier than I have ever been...

The Introl and Ciprico controllers I was using at the same time on
VME based systems came with full documentation, did DMA and
vectored interrupts properly, and handled disconnect/reconnect,
synchronous transfers and multiple initiators.

I agree with you that the PC plug in cards are usually cheaper.
But this is just a function of the PC market dominance forcing up
the price of alternatives by denying them economies of scale.

> IDE hasn't been that primitive for years.  indeed, probably the main complaint
> i'd make about PCs is that things sometimes change so often in various ways
> (ether, graphics, etc) that it's hard to keep up.   mind you, that was true
> in different ways with Sun and SGI.
>
> indeed, the most useful non-Intel platform i've used was the BeBox,
> because although it was PowerPC, it had ISA and PCI slots
> (and a useful NCR scsi chip) just like .... errr ... a PC.  it was
> dual-processor, though, long before the normal PC (but no secondary cache).

The PCI bus is being adopted by many systems more or less in parallel,
which just means that bus is ceasing to be a distinguishing factor
when comparing ease of adding hardware.

IDE is getting better (or at least less limitted), but it is still
far easier to add hardware using SCSI than IDE. The unfortunate
trend for other systems like BeBox and MBX to include IDE rather
than SCSI, which is technologically a backward step is, as far as
I can see, an unfortunate necessity in order to take advantage of
the lower price IDE disks that result from the higher volume sales.

Regards,
DigbyT
--
Digby R. S. Tarvin                                              digbyt@acm.org
http://www.cthulhu.dircon.co.uk




^ permalink raw reply	[flat|nested] 4+ messages in thread

* [9fans] Re: PC capability
@ 2000-05-04 18:55 forsyth
  0 siblings, 0 replies; 4+ messages in thread
From: forsyth @ 2000-05-04 18:55 UTC (permalink / raw)


it no doubt depends on which workstations and PCs we've experienced.

for instance, i would never choose SCSI as an example, because from the earliest
days of my experiences with 386 PCs and above, the SCSI adapters i was able to use
-- even ISA ones -- were fairly cheap, better documented, easier to handle
(ie did more, and that sensibly), and much faster than the SCSI
interfaces on equivalent Sun-3s and Sparcs, and even MIPS, that cost much more.

IDE hasn't been that primitive for years.  indeed, probably the main complaint
i'd make about PCs is that things sometimes change so often in various ways
(ether, graphics, etc) that it's hard to keep up.   mind you, that was true
in different ways with Sun and SGI.

indeed, the most useful non-Intel platform i've used was the BeBox,
because although it was PowerPC, it had ISA and PCI slots
(and a useful NCR scsi chip) just like .... errr ... a PC.  it was
dual-processor, though, long before the normal PC (but no secondary cache).




^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2000-05-08  9:14 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-05-05 14:38 [9fans] Re: PC capability Digby
  -- strict thread matches above, loose matches on Subject: below --
2000-05-08  9:14 Jolt-Freak
2000-05-05 14:10 Digby
2000-05-04 18:55 forsyth

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).