Is U160 REALLY Faster than Ultra-Wide on SCO?
Neal Rhodes
the Netraid/AMI Megaraid controller.
The obvious route is an external Kingston cabinet, and more
Ultra-wide drives. It looks like I can't get 10,000 rpm drives with
a 68pin Ultra-wide connector any more.
The non-obvious route is to install yet another RAID controller, and
run U160 (? 160mb/sec) cables to an external cabinet, and use U160
80pin SCA drives. Here I can get Seagate Cheetah's, which are
10,000 rpm. Which results in obviously more cost and complexity.
The last time I did significant benchmarking, I found that drives
could provide impressive throughput on a single sequential task on
large files, like, uhhh, backup. However, when you threw many
random i/o operations at them, physics of slamming the head around
took over and the difference between Wide Scsi and Ultra Wide Scsi
wasn't really noticable.
The application here is a large Progress Database, with lots of
updates, and much random i/o.
I'm wondering if the advantage of Ultra-Super-wide-and-really-fast
u160 Scsi is significant over Ultra Wide Scsi in the real world of
random database i/o with no more than 4 drives on a single
SCSI channel.
Thoughts anyone?
--
------------------------------------------------------------------------------
Neal Rhodes MNOP Ltd (770)-
972-5430
President Lilburn (atlanta) GA 30247 Fax:
978-4741
ne...@mnopltd.com
http://www.mnopltd.com/
Jeff Liebermann
<ne...@dexter.mnopltd.com> wrote:
>I'm wondering if the advantage of Ultra-Super-wide-and-really-fast
>u160 Scsi is significant over Ultra Wide Scsi in the real world of
>random database i/o with no more than 4 drives on a single
>SCSI channel.
Just barely with a 32bit OS and a 32bit/33Mhz PCI bus.
The Adaptec 29160 series of adapters will do 160MBytes/sec. The
typical drive will do 40MBytes/sec. Therefore, you need to stripe 4ea
drives to get the full 160MBytes/sec. With older 20MBytes/sec drives,
you'll need an 8 drive RAID stripe.
However, the 32bit 33Mhz PCI bus will only move 133MBytes/sec maximum
(on a good day). If your full duplex Gigabitch ethernet is running at
the same time, say goodby to 100MBytes/sec for both input and output
accross the PCI bus. Therefore, you need a 64bit/66Mhz PCI bus and 64
bit operating system to take advantage of the full 160MBytes/sec
bandwidth.
Ultra 160 Overview
http://www.adaptec.com/products/overview/ultra160scsi.html
Ultra 160 vs SCSI2
http://www.adaptec.com/technology/whitepapers/ultra160m.html
Methinks most of the related white papers are worth reading.
Note that OSR5 does not currently support the Adaptec 29160, but a
driver is promised in June.
Robert Lipe
>On Fri, 28 Apr 2000 16:06:12 -0400, Neal Rhodes
><ne...@dexter.mnopltd.com> wrote:
>>I'm wondering if the advantage of Ultra-Super-wide-and-really-fast
>>u160 Scsi is significant over Ultra Wide Scsi in the real world of
>>random database i/o with no more than 4 drives on a single
>>SCSI channel.
>Just barely with a 32bit OS and a 32bit/33Mhz PCI bus.
I'll basically support Jeff's answer, but pick on a few minor nits.
>The Adaptec 29160 series of adapters will do 160MBytes/sec. The
>typical drive will do 40MBytes/sec. Therefore, you need to stripe 4ea
>drives to get the full 160MBytes/sec. With older 20MBytes/sec drives,
>you'll need an 8 drive RAID stripe.
Note that's a sustained I/O number. Drives that'll do faster than 40
aren't hard to find. Drive that'll burst (from cache) above 40 are easy
to find.
>However, the 32bit 33Mhz PCI bus will only move 133MBytes/sec maximum
>(on a good day). If your full duplex Gigabitch ethernet is running at
True.
>the same time, say goodby to 100MBytes/sec for both input and output
>accross the PCI bus. Therefore, you need a 64bit/66Mhz PCI bus and 64
>bit operating system to take advantage of the full 160MBytes/sec
>bandwidth.
Not so true. OS support for 64bit PCI addressing is orthogonal to it
being a 64 bit OS. For example, UnixWare 7 can support 64 bit pci
addressing when running on Pentia-class 32 bit processors.
Certainly the widened hose between the HBA and the system memory helps.
Jeff's punchlines is certainly valid: If you're sticking a single drive
on a U160 HBA on a system with 32 bit PCI and expecting your database
to run faster, dream on. If you're running an array of modern (fast)
drives on a system that can really take advantage of the new 64-bit PCI
HBAs, it's an inexpensive boost.
(Of course, if so, you're already running a system that's so expensive
that the cost of the HBA is nothing...)
RJL
Jeff Liebermann
>I'll basically support Jeff's answer, but pick on a few minor nits.
Nobody ever agrees with me. I'm not sure I know how to handle agreement.
>>the same time, say goodby to 100MBytes/sec for both input and output
>>accross the PCI bus. Therefore, you need a 64bit/66Mhz PCI bus and 64
>>bit operating system to take advantage of the full 160MBytes/sec
>>bandwidth.
>
>Not so true. OS support for 64bit PCI addressing is orthogonal to it
>being a 64 bit OS. For example, UnixWare 7 can support 64 bit pci
>addressing when running on Pentia-class 32 bit processors.
It was my impression (i.e. I wasn't paying attention) that 64bit PCI
requires that every card on one side of the PCI bridge chip also be 64bit.
Shove a junk video card on the same bus, and say goodby to 64bit transfers.
I also vaguely recall that scatter gather (basically DMA block transfers
from ram directly to the SCSI adapter) also requires 64 bit OS support.
Even if 32/64bit PCI mode mixing were possible, running at 32bits part of
the time would certainly be a big performance hit. So, how wrong am I?
>Jeff's punchlines is certainly valid: If you're sticking a single drive
>on a U160 HBA on a system with 32 bit PCI and expecting your database
>to run faster, dream on. If you're running an array of modern (fast)
>drives on a system that can really take advantage of the new 64-bit PCI
>HBAs, it's an inexpensive boost.
Also, it was my understanding that RAID striping is limited by the sustained
transfer rate of the drives. If one drive of the stripe decides to
re-calibrate or flush its cache, then the other drives automagically slow
down until it catches up. That's why I used the sustained transfer rates
instead of the burst rates in my guestimates. Besides, the burst rate seems
to be mostly determined by the size of the hard disk ram cache. Once the
cache is full, it's back to real sustained transfer rates.
--
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
je...@comix.santa-cruz.ca.us je...@cruzio.com
Robert Lipe
>On Sat, 29 Apr 2000 15:33:18 GMT, Robert Lipe <rober...@usa.net> wrote:
>>I'll basically support Jeff's answer, but pick on a few minor nits.
>Nobody ever agrees with me. I'm not sure I know how to handle agreement.
I'll pick a fight if it makes you feel better, but I'd prefer to get back
to the technical stuff pretty quickly.
Your truck is funny looking. :-)
>It was my impression (i.e. I wasn't paying attention) that 64bit PCI
>requires that every card on one side of the PCI bridge chip also be 64bit.
>Shove a junk video card on the same bus, and say goodby to 64bit transfers.
I'm looking at MindShare book on PCI 2.1. The specification goes to
great detail to allow independent autonegotiation of 64 bit address, 64
bit data. So (modulo chipset bugs and implementation lameness) I don't
think that plugging in a 32 bit card onto your 64 bit bus will neuter the
64-bit capabilities of the rest of the system.
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.
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.
>I also vaguely recall that scatter gather (basically DMA block transfers
>from ram directly to the SCSI adapter) also requires 64 bit OS support.
>Even if 32/64bit PCI mode mixing were possible, running at 32bits part of
>the time would certainly be a big performance hit. So, how wrong am I?
64 bit addressing and 64 bit data are independent. Both of those are
independent of whether the host processor is 64 bits. But both do need
host driver (and some host OS) support.
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.)
>Also, it was my understanding that RAID striping is limited by the sustained
>transfer rate of the drives. If one drive of the stripe decides to
At some level of RAID, I'm sure this is true. You have to get that
data onto a spinning round thing some time. If you build a RAID stripe
out of crappy drives, you're still hosed. Drives that can sustain
25-50MB/sec of data aren't uncommon.
>re-calibrate or flush its cache, then the other drives automagically slow
>down until it catches up. That's why I used the sustained transfer rates
>instead of the burst rates in my guestimates. Besides, the burst rate seems
>to be mostly determined by the size of the hard disk ram cache. Once the
>cache is full, it's back to real sustained transfer rates.
It's a matter of having more options to move around bottlenecks.
Depending on the system and the load pattern, the bottleneck might
be in any of:
A) Host PCI saturation
B) SCSI bus saturation
C) burst drive saturation
D) sustatined drive I/O saturation
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.
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.
Jeff Liebermann
> 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?
Robert Lipe
>On Sat, 29 Apr 2000 19:31:21 GMT, Robert Lipe <rober...@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
Neal Rhodes
>
> Jeff Liebermann <je...@comix.santa-cruz.ca.us> writes:
>
> >On Sat, 29 Apr 2000 19:31:21 GMT, Robert Lipe <rober...@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.
>
Thanks for the responses, and I'm glad you two have come to a
better relationship over this topic.
Back to the subject, I'm still thinking that although drives might
sustain throughput in excess of 40mb/sec in sequential access, once
they start seeking all over the place in random access their access
time will go down the toilet.
Since this posting, I contacted Seagate Presales Support, and their
general take was that if you had more than 12 drives on a channel,
then U160 would be a win; with 2 or 4 drives on a channel, you
probably won't notice.
Jeff Liebermann
>>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.
Yep. The 29160 is $300. The 29160N is $280. (From Warehouse.com).
Save $20 and get 1/4 the (theoretical) performance.
>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.
(...)
>So it's potentially negotiated on each PCI transaction.
Ah. Now I see. You have to poll the device before each transaction of
features like Hot Swap PCI won't work. Got it.
>Oh, all right. It wasn't the best example. But you get the point.
I do? Oh, right. I get it. I think... Maybe I'll do some more reading.
>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.)
Got it. Enabling a 64bit bus width automagically presumes that all
transfers will be on 64bit byte boundaries. That's too easy. I should have
seen that. More reading...grumble.
>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.
Web, news, and mail servers are more like the former. All the traffic is
either from the network to the drive, for from the drive to the network.
Occassionally some drive to drive, but not much. Therefore, if the network
traffic is (conveniently) equal to the SCSI bus traffic on the PCI bus, the
problem is severe. With half the bus width and half the data rate, the
32bit gigabit ethernet card will move one byte for every 4 bytes of SCSI
adapter traffic. The SCSI adapter will be sitting there for 3 out of 4
clock cycles for every one clock cycle to the ethernet card. Actually, this
is yet another guess as there's overhead for both ethernet and SCSI which
may not be equal. The 32bit ethernet card counts as a *MAJOR* performance
hit to the PCI bus. sar statistics should show the SCSI adapter instruction
queue to be perpetually full. Therefore, (sound of drum roll) just shoving
a 29160 into a system isn't gonna do much without scaling the rest of the
system.
>>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."
I'm not worried. Every time there's an advance in hardware technology, the
software types step in and add features and acronyms that slow the system.
(Drivel: You'll be amazed at how fast Windoze 3.11 runs on PIII/500). Even
the hardware vendors help slow things down. Intel's PIII/xxx-e series, with
half the L2 cache is a good example. It's all a conspiracy to control
performance and prevent the appearance of major performance gains. I still
contend that it is impossible to benifit from UW-160 (SCSI3) without also
replacing just about everything.
>>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.
Yep. I've seen far too many "bottlenecks" fixed by just adding more RAM
without the slightest shred of evidence or testing. That's the standard
answer for most performance problems. If the disk drive appears to be
beating itself to death (watch the flashing lights), then obviously RAID is
the answer to all problems. That's why I like Sarcheck. The
recommendations are in English and at a level that can be understood by the
average bean counter.
>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.
It doesn't work that way. The cloud of black smog that follows me
everywhere functions as an anti-tailgating device and discourages
car-jackers. The graphite in the cloud absorbes radar signals which makes
me invisible to speed traps. The rattle noises insure that I will be heard
as well as seen and smelled. I could get some of the stuff that the bus and
taxi guys use to hide the smell. It doesn't really get rid of the smell but
just desensitizes your nose.
>You could fix all of those things and I still wouldn't like it. I just
>don't like trucks.
It has 249,000 miles on it. If it looked nice, smelled good, was
comfortable, made no noise, and wasn't hidden in a cloud, it wouldn't have
made it past the warranty period.
> See also: identifying and fixing specific bottlenecks. :-)
# man bottleneck
man: bottleneck not found
Where's the man page on bottlenecks?
Jeff Liebermann
wrote:
>Since this posting, I contacted Seagate Presales Support, and their
>general take was that if you had more than 12 drives on a channel,
>then U160 would be a win; with 2 or 4 drives on a channel, you
>probably won't notice.
Any you believed them? Seagate is in the business to sell disk drives. I'm
suprised they didn't suggest you buy the full 15 drives per channel.
Geoff Johnson
Are you feeding a video server or a text web site.
The massive transefer rates already dominate the seek times for anything
but the largest data transfers.
If you have a database with a 2K blocks size you can run 15 disks per
channel
without loosing any sleep.
Do the sums, look at your existing wait and service times and compare
them to the
data transfer times for the size of IO involved. The ratio give you an
idea of
how many drives you can have on the bus.
Jeff Liebermann wrote:
>
> On Sun, 30 Apr 2000 22:44:26 -0400, Neal Rhodes <ne...@dexter.mnopltd.com>
> wrote:
>
> >Since this posting, I contacted Seagate Presales Support, and their
> >general take was that if you had more than 12 drives on a channel,
> >then U160 would be a win; with 2 or 4 drives on a channel, you
> >probably won't notice.
>
> Any you believed them? Seagate is in the business to sell disk drives. I'm
> suprised they didn't suggest you buy the full 15 drives per channel.
> --
> 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
> je...@comix.santa-cruz.ca.us je...@cruzio.com
--
Geoff Johnson
Robert Lipe
>On Sun, 30 Apr 2000 22:11:28 GMT, Robert Lipe <rober...@usa.net> wrote:
>>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.)
>Got it. Enabling a 64bit bus width automagically presumes that all
>transfers will be on 64bit byte boundaries. That's too easy. I should
>have seen that. More reading...grumble.
Sort of. The DMACs should be smart enough to only drive the appropriate
lane enables for the data to actually be transferred. If, for example,
a read is mastered and you're transferring 8 bytes starting at address
4, 32-bit PCI will drive two cycles. The first will burst the 32 bits
starting at address zero with only the last two byte enables held high
and the second will 32 bits with only the first two lanes held high.
Subword accesses are well defined. At the logic analyzer level, yes,
PCI tries hard to make sure everything is word sized. But once you hook
up the pins and look at the byte enable signals, you can easily see
transfers that aren't _really_ "appropriately" aligned. The programmers
don't have to artificially align these things.
>>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.
>Web, news, and mail servers are more like the former. All the traffic
>is either from the network to the drive, for from the drive to the
>network. Occassionally some drive to drive, but not much. Therefore,
>if the network traffic is (conveniently) equal to the SCSI bus traffic
>on the PCI bus, ... just shoving a 29160 into a system isn't gonna do
>much without scaling the rest of the system.
True. If you're moving byte-for-byte from one source to the other (something
I posit as atypical) then making one source faster is a false god to worship.
RJL