Why PCI?

# 2 Why PCI?

Contents of this section

## 2.1 General overview

The PC-architecture has several BUS-Systems to choose from:

ISA

  cheap, slow (usually 8Mhz), standard, many cards available>

EISA

  expensive, fast, some cards available>

MCA

  ex-IBM-proprietary, fast but not very wide-spread>

VESA-Local-Bus

  based on ISA, cheap, fast, some cards available>

PCI-Local-Bus

  expensive, fast, some cards available, the upcoming standard>

ISA/VESA-Local-Bus had some problems with high bus-speeds, and was not very reliable, but mainly due to its low price and better-than-ISA performance, sold very well. Most VESA boards should be stable by now.

EISA was reliable, but rather expensive, and intended more for power-users and servers, than for the average user. It has fewer cards available than other busses.

PCI now has the advantage. Like EISA it is not proprietary. It is as fast as EISA (or even faster), and 64bits wide. This will be important with the i586 (That Intel would prefer we call the Pentium...).

PCI is not like ISA/Local-Bus processor-dependent. This means you can use the winner-1000-PCI in an Alpha-driven-PCI-board as well as in a i486/i586-driven PCI-Board, except for the BIOS, but the hardware should be the very same.)

PCI allows cheaper production of onboard components, and needs no glue-logic chips.

## 2.2 Performance

taken from Craig Sutphin's Pro-PCI-Propaganda

> Unlike some local buses, which are aimed at speeding up graphics alone, the PCI Local Bus is a total system solution, providing increased performance for networks, disk drives, full-motion video, graphics and the full range of high-speed peripherals. At 33 MHz, the synchronous PCI Local Bus transfers 32 bits of data at up to 132 Mbytes/sec. A transparent 64-bit extension of the 32-bit data and address buses can double the bus bandwidth (264 Mbytes/sec) and offer forward and backwards compatibility for 32 and 64-bit PCI Local Bus peripherals. Because it is processor-independent, the PCI Local Bus is optimized for I/O functions, enabling the local bus to operate concurrent with the processor/memory subsystem. For users of high-end desktop PC's, PCI makes high reliability, high performance and ease of use more affordable than ever before; no trivial task at 33 MHz bus-clock rates. Variable length linear or toggle mode bursting for both reads and writes improves write dependent graphics performance. By comprehending the loading and frequency requirements of the local bus at the component level, buffers and glue logic are eliminated.

## 2.3 The onboard-SCSI-II-chip NCR53c810

One very nice feature of some PCI mother boards is the NCR onboard-SCSI-II-chip, which is said to be as fast as the EISA-Adaptec-1742, but much cheaper. Drivers for DOS/OS2 are available. Drew Eckard has released version 3 of his NCR53c810-driver, but it is not in the default kernel yet. The Slackware-distribution 2.0 is said to have boot disks for it by now. There are also patches available for kernel 1.1.19, but they needed some manual patching. I myself am running 1.1.45 which does not require separate patches anymore, the driver is already part of that kernel.

This works perfectly except one thing: the system call which reports the disk geometry does not satisfy LILO. It works ok for the whole drive, but not for partitions. Therefore fdisk works ok, but LILO does need the information in /etc/disktab, and it is important to have an entry for every partition in that file. For me it is

    0x800   0x80    32      64      1006    0
    0x801   0x80    32      64      1006
    0x802   0x80    32      64      1006
    0x803   0x80    32      64      1006

Where 0x800 is /dev/sda, 0x80 means first scsi-device, 0x801 is /dev/sda1 etc.

You can find out the disk geometry by using the dparam.com under DOS. DPARAM.COM comes with lilo and is also included in the SCSI-HOWTO. (I recommend reading that one, it was very interesting to me.)

Apart from this, the driver performs pretty well, and I never lost a single byte. People have already moved gigabytes of data safely with it.

Alternately, it is easy to apply a patch by hand or just wait until it has gotten part of the kernel. All you have to do is change the line in /usr/src/linux/drivers/scsi/scsicam.c containing "bread" from:

            ...bread(dev,...
    to:
            ...bread( (dev & ~0xf),...

This fixes the bug and I hope does not break anything else. Maybe it is already part of the kernel after 1.1.45.

This works so well I sold my adaptec-1542B-ISA :-)

The NCR53c810-chip is onboard on many PCI-motherboards. There are add-on-boards available too, for about US$ 70.00.

The NCR-patches and bootimages are available on tsx-11.mit.edu:/pub/linux/ALPHA/scsi/ncr (approximately). Newer releases of Slackware 2.0 have support for the ncr too. Newer versions of the test-kernels (1.1.41 for example) do not require any patches; they have the driver already included.

Drew said about the SCSI on PCI: (slightly edited for clarity in context)

> Currently, your only PCI SCSI option that stands a chance of working is the Buslogic 946. It purports to be Adaptec 1540 compatible, like the EISA/VESA/ISA boards in the series.

> I'm working on getting the Linux NCR53c810 driver stable, some one else is doing the same thing for one of the BSD flavors.

> This chip, offering fast busmastering, is included on motherboard implementations, and is (supposedly) available for US$ 100.00 on cards without BIOS (because many of the PCI boards that don't include the NCR chip onboard still do have the NCR BIOS).

> This covers the majority of PCI SCSI adapters on the market (Nexstor, Chaintech, Gigabyte, FIC, etc). Adaptec is shipping (see below) a FAST WIDE version of the AIC-7770 with a PCI interface, and AIR is using it on their Pentium boards, but I haven't seen any separate board level product with it.

> Scott Ferris is working on the AIC-7770 driver under Linux, but I don't know of anyone doing the same thing under one of the BSDs.

> Emulux also has a propriety FAST+WIDE PCI controller. It's unlikely that it will show up as supported under one of the BSD's or Linux anytime soon, since the NCR based controllers are cheaper and more prevalent. Further, the NCR-equipped motherboards are often as cheap, or cheaper, than similar non-SCSI equipped boards.

> The Buslogic PCI controllers are compatible with the 1540 (thus offering only that level of performance), so I doubt many Linux'ers will buy them.

> Forex is shipping a PCI SCSI adapter, I don't have details.

Also note that since he said this, Drew has a working 810 driver out.

James Soutter (J.K.Soutter1@lut.ac.uk) asked me to add the following information on Fast-Wide-SCSI-2:

> Fast Wide SCSI-2 is sometimes incorrectly called SCSI-3. It differs from the normal Fast SCSI-2 (like the Adapted 1542B?) because it uses a 16 bit data bus rather than the more usual 8 bit bus. This improves the maximum transfer rate from 10 MB/s to 20 MB/s but requires the use of special Fast Wide SCSI-2 drives.

> The added performance of Fast Wide SCSI-2 will not necessarily improve the speed of your system. Most hard disk drives have a maximum internal transfer rate of less than 10 MB/s and so one drive alone can not flood a FAST SCSI-2 bus.

> In Seagate's Oct 1993 product overview, only one Fast Wide SCSI-2 drive has an internal transfer rate of more than 10 MB/s (the ST12450W). Most of the drives have a maximum internal transfer rate of 6 MB/s or less, although the ST12450W is not the only exception to the rule. In conclusion, Fast Wide SCSI is designed for the file server market and will not necessarily benefit a single user workstation style system.

> Rather than buying a PCI system with a SCSI interface on the motherboard, or rather than waiting for the NCR driver, you could purchase a separate PCI based SCSI card. According to Drew, the only PCI SCSI option that stands a chance of working is the Buslogic 946. It purports to be Adaptec 1540 compatible, like the EISA/VESA/ISA boards in the series.

> Drew commented that other PCI based SCSI controllers are unlikely to be supported under Linux or the BSD's because the NCR based controllers are cheaper and more prevalent.

I personally would tend to try the NCR-Driver.

According to broom@ocean.fit.qut.edu.au (Bradley Broom):

> The Buslogic BT-946C PCI SCSI works if you disable the option "enable Disconnection" with the AUTOSCSI-program under DOS which comes with the card.

Ernst Kloecker (ernst@cs.tu-berlin.de) wrote: (edited)

> Talus Corporation has finished a NS/FIP driver for PCI boards with NCR SCSI. It will be shipping very soon, might even be free because a third party might pay for the work and donate the driver to NeXT.

Not every PCI-Board has got the chip. ASUS does, and one of the J-Bond boards does, too. Some vendors provide an alternative as you can read in Drew's text...

The NCR-Chip is clever enough to work with drives formatted by other controllers, and should be no problem.

Next Chapter, Previous Chapter

Table of contents of this chapter, General table of contents

Top of the document, Beginning of this Chapter