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:33:39 2000
Path: news.randori.com!feed2.onemain.com!feed1.onemain.com!newsfeed.berkeley.edu!sn-xit-03!supernews.com!sn-inject-01!corp.supernews.com!not-for-mail
From: Robert Lipe <robertlipe@usa.net>
Newsgroups: comp.unix.sco.misc
Subject: Re: Is U160 REALLY Faster than Ultra-Wide on SCO?
Date: Sun, 30 Apr 2000 22:11:28 GMT
Organization: Posted via Supernews, http://www.supernews.com
Lines: 142
Message-ID: <sgpbsguqo6q140@corp.supernews.com> 
References: <3909EF34.41C6@dexter.mnopltd.com> <t22lgskru2funeap3gjapk3iu3ohj70i78@4ax.com> <sgm05und7qo19@corp.supernews.com> <735mgs40ojmf05u4ptndd7gu30ncs2jqep@4ax.com> <sgme4922i50117@corp.supernews.com> <ohmogs4jbqo6e205kge4hsvg1ti8dn72kr@4ax.com> 
Reply-To: robertlipe@usa.net
X-Complaints-To: newsabuse@supernews.com
X-Newsreader: NN version 6.5.0 CURRENT #118
Xref: news.randori.com comp.unix.sco.misc:59204
X-Mozilla-Status: 8010
X-Mozilla-Status2: 00000000

Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> writes:

>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.

Glad to help.

>>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?  

My guess?  Cost.  Narrow scsi and 64-bit PCI just don't seem like a
natural pairing.  Those extra pins and bus interface chips aren't free.

>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.  

The question isn't really doing it "on the fly".  The system knows the
width and speed of the source and destination and everything in between
it, so it can be predetermined if you know the destination is 32 address
bits, just never wind up a 64 address bit transfer.

>It's not just the data rate, but the data/clock encoding method that
>changes.

There's plenty of prior art for that already in PCI.  Dual-address
cycle, for example...

>not a mixture.  Even if the PCI bus could switch speeds on the fly, I
>suspect there's considerable overhead and timing issues involved.

My reading of the spec is that REQ64# is asserted.  The target either
grants ACK64# or it doesn't.  Just like any other mastered transaction.
But since you can know in advance that a 64 bit transaction isn't
possible, you don't have to negotiate it in the cases where you know it
will be false.

>>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

>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

Oh, all right.   It wasn't the best example.   But you get the point.

>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

My reading of the MindShare book (combined with some economic/business
sense) says that it can.   From page 247:

   At the beignning of a transaction, the 64-bit bus master
   automatically senses if the responding target is a 64-bit or a 32-bit
   device.

So it's potentially negotiated on each PCI transaction.

>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.  

That's what the lane enables on the bus are for.  Just like you can DMA
an odd number of bytes on a 32 bit PCI bus and expect it to not trash
memory past the destination you can expect this to work on a 64-bit
target with a 32-bit initiator, too.  (See above.)

> Also, I saw an NT TSE server with 4GB of RAM last week.

Sure.  Systems with > 4Gb of RAM aren't unheard of - espeically in the
UnixWare camp.  OpenServer systems with 4G are considerably more rare.


>>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.

Your original example referenced a crappy video card hogging the bus.
My point was that if you're saturating the PCI bus with traffic, don't
expect having a faster SCSI bus to make your system run better.

>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).  

Database transactions tend to be more like the latter than the former.
They spend their lives picking stuff up from the disk and putting it
back down on the disk.  But different systems will surely exhibit
different characteristics.

>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.  

I posit those are somewhat independent.  But it's true that in any given
system, something will always be the slowest.

A coworker once commented, "There will always be a number one killer of
our citizens."

>Just shoving in a 29160 doesn't buy much.

Unless it solves the very specific problem that any given user may or
may not have.  As with all performance tweaks, identifying and measuring
the problem is the hard part of solving it.



>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?

Well, if I were the pollution board (informix user), I might find only
the smell (SCSI bus bandwidth) to be unacceptable.  Fixing that alone -
even though one might be tempted to lump them all together since they're
all sort of related to "truck desirablility" (performance)- would
probably make that truck acceptable to the pollution board (user). So
to the PB's view, only the diesel smell is the limiting factor and
upgrading that would make it a nicer truck.


You could fix all of those things and I still wouldn't like it.  I just
don't like trucks.

See also: identifying and fixing specific bottlenecks. :-)


RJL

Macworld Digital Photography Superguide

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.