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.

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

SpamCheetah
Stop spam dead in its tracks!

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.