A.P. Lawrence

32 bit vs 64 bit scsi dma 2940 pci

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From - Mon May  1 06:32:10 2000
Path: news.randori.com!hermes.visi.com!news-out.visi.com!news-out.transit.remarq.com.MISMATCH!sn-xit-03!supernews.com!sn-inject-01!corp.supernews.com!not-for-mail
From: Jeff Liebermann <jeffl@comix.santa-cruz.ca.us>
Newsgroups: comp.unix.sco.misc
Subject: Re: Is U160 REALLY Faster than Ultra-Wide on SCO?
Date: Sun, 30 Apr 2000 10:25:54 -0700
Organization: Committee To Maintain an Independent Xenix
Lines: 117 Message-ID: <ohmogs4jbqo6e205kge4hsvg1ti8dn72kr@4ax.com> References: <3909EF34.41C6@dexter.mnopltd.com> <t22lgskru2funeap3gjapk3iu3ohj70i78@4ax.com> <sgm05und7qo19@corp.supernews.com> <735mgs40ojmf05u4ptndd7gu30ncs2jqep@4ax.com> <sgme4922i50117@corp.supernews.com>
Reply-To: jeffl@comix.santa-cruz.ca.us
X-Complaints-To: newsabuse@supernews.com
X-Newsreader: Forte Agent 1.8/32.548
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Xref: news.randori.com comp.unix.sco.misc:59198
X-Mozilla-Status: 8010
X-Mozilla-Status2: 00000000

On Sat, 29 Apr 2000 19:31:21 GMT, Robert Lipe <robertlipe@usa.net> wrote:

>    Your truck is funny looking. :-)

Thanks.  Now, I feel better.  I find it difficult to discuss technical
issues without first finding some issue I disagree with.

>Of course, it is a shared medium.  So if you have a PCI bus that's
>largely saturated by a 32 bit card, the reality is that your 64 bit card
>will be penalized by being forced to negotiate for the bus more often.

Ok.  So why did Adaptec release the 32bit only 29160N board?  The 29160 and
39160 can both work on either a 33MHz (32bit) or 66MHz (64bit) bus, but I
don't think it can switch speeds on the fly.  It's not just the data rate,
but the data/clock encoding method that changes.  There's not enough info on
the AIC-7899 data sheet http://www.adaptec.com/pdfs/aic-7899v2.pdf to
determine if it's possible.  My *GUESS* is that it's one speed or the other,
not a mixture.  Even if the PCI bus could switch speeds on the fly, I
suspect there's considerable overhead and timing issues involved.

Control Spam and Viruses

Run your own mailserver

Incidentally, the performance difference between 33MHz 32bit (133MBytes/sec)
and 66Mhz 64bit (532MBytes/sec) is rather substantial.

>It's not entirely unlike having a 10Mb laser printer on your 100Mb
>ethernet network.  The time your printer is on the wire, your 100Mb
>stuff can't be on the wire.  It isn't like your 100Mb devices will all
>slow down to 10 just becuase there happens to be one thing on the wire
>that's slower.  So you try to architect the system so that your biggest
>consumers of bandwidth use the fastest possible scheme and the slower
>consumers - be they PCI or Ethernet - stay out of the way as much as
>possible.

Very bad example.  10barfT and 100barfT *NEVER* share the same wires or
signal paths.  There's no contention issues or changes in speed on a given
cable.  It's either 10 or 100, never both, and never changing.  A dual speed
hub is actually two hubs in one box, with a speed detector on each port.
The port is switched to the proper speed hub.  Speed differential issues are
handled with a highly buffered bridge between the two hubs.

PCI is different.  It's a bus, not a star, topology.  Everything has to
coexist on the same PCI bus.  As always, timing is everything.  PCI is an
unterminated bus that relies up the reflected signal off the end of the bus
to reinforce the incident signal.  This is why PCI buses are rarely more
than 4 PCI sockets long.  I've always been impressed that PCI even
functions, but to have the data rate successfully change on the fly, without
a performance penalty, would really impress me.  

Duz the PCI 2.1 spec allow for 32bit and 64bit devices to coexist on the
same side of the bridge chip and allow changes in both speed and bus width
on the fly?  I've dug through the various web piles (i.e. Intel) on the
topic and found nothing specific.

>On an OS like OpenServer where 4Gb of RAM is, errr, uncommon, 64 bit
>addressing is somewhat pointless.  But 64-bit data transfers can still
>be effectively used if the host drivers carefully craft the DMA setups.
>(I don't know which drivers do or don't in OSR5; I'm speaking only that
>it might be done.)

I suspect that transferring blocks of data via DMA, to a 64bit device, in
32bit wide chunks would probably cause byte alignment problems.  Any odd
numbered blocks might be 50% garbage.  Also, I saw an NT TSE server with 4GB
of RAM last week.

>If you build a RAID stripe
>out of crappy drives, you're still hosed.

Not crappy.  Just not exactly identical.  The problem normally does not
occur on new installations where all the drives are presumed to be exactly
identical.  It's when one of the drives gets replaced a year later, and the
driver manufactory has made firmware changes.

Incidentally, RAID originally meant "Random Array of Inexpensive Drives",
but was changed to "Redundant Array of Independent Disks" for obvious
reasons.

>Drives that can sustain
>25-50MB/sec of data aren't uncommon.

Sure.  Ultra-2 SCSI can barely sustain 80MBytes/sec with a 10,000 RPM drive
and LVD (low voltage differential) interface and somewhat less with 7200
RPM.  Ultra SCSI can do 40MBytes/sec with either spin and any connector.

>If your host PCI bus is soaked becuase you're running xico on some piece
>of crap video card with the vesa server all the time, don't expect
>swapping in one of these new U160 cards to help.

I look at it a bit differently.  If you have an OSR5 SMB (small-medium
business) application that can benifit from or requires 160MBytes/sec
aggregate data transfer rate, then you wouldn't be running X11 games on this
machine.

>But if you're bound on item B and think that you can keep the HBA full
>of incoming data and drained of outoing data on both ends, then U160 is
>a help.

I look at it a bit differently.  Having a drive array that can move
160MBytes/sec is cool.  Shared the same PCI bus with a Gigabit ethernet card
is a great way to loose over half the bandwidth.  The 160Mbytes/sec has to
come from somewhere and go somewhere (unless your application like to just
copy files from drive to drive).  If increasing the peak burst data rate is
of importance, then a big disk cache (hint: increase NBUF/NHBUF) would have
a much bigger effect.  Increasing SCSI bus bandwidth requires, increasing
the network i/o bandwith, which requires increasing the PCI bus bandwidth,
which requires increasing the memory performance (to get 64bit 66Mhz zero
wait state performance), which requires a faster CPU, ad nausium.  Just
shoving in a 29160 doesn't buy much.

Now, what about my truck don't you like?  Is it the peeling paint, the
disintegrating upostery, the myriad of antennas, the clouds of diesel black
smog, the diesel smell, or the rattle trap sounds it makes?

-- 
Jeff Liebermann  150 Felker St #D  Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.cruzio.com/~jeffl   WB6SSY
jeffl@comix.santa-cruz.ca.us   jeffl@cruzio.com

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

Unix and Linux Support

/Bofcusm/334.html copyright 1997-2004 (various authors) All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here