IDE/SCSI bus transfer rates

[subflava]

I've always wondered about the theoretical transfer rates of IDE/SCSI buses are actually approached when you put multiple drives on the bus(actually this could apply to any sort of shared data bus):

Let's say you have a single-channel SCSI controller capable of 160MB/s transfer rate. If you were to install a single SCSI drive (also supports 160MB/s transfer) capable of a sustained transfer rate of ~30MB/s (sustained as in from the internal/disk platter to drive buffer) then you should be able to measure ~30MB/s transfer rate on the controller/bus itself. One might naturally ask, "What good is having a 160MB/s bus if the drive can only pump out data at 30MB/s?" The answer is that in situations where there are multiple devices on the bus, then you need the extra bandwidth for the other devices. So taking our previous example, if we put 2 drives on the bus then we should be able to measure a sustained transfer rate of ~60MB/s. With 3 drives, ~90MB/s and so on until we get near the 160MB/s limit.

My question is this: Assuming that only 1 device at a time can transmit data at any given point in time, how can the SCSI bus actually transmit data faster than 30MB/s in this example? So if during time period 1, drive #1 is transmitting data at 30MB/s no other drive should be able to transmit data or else there would be a collision (??) Any other drive wanting to transmit data would have to wait till time period 2, etc. Based on this reasoning, you should never measure more than the sustained transfer rate of one single drive on the bus. However, in the real world people *do* measure higher sustained transfer rates so obviously the transfer rates are adding up somehow.

Can anyone enlighten me as to how this works?

 

[alpha88]

SCSI devices aren't limited to one active per channel like IDE is, thats the biggest advantage of the protocol.

 

[subflava]

<< SCSI devices aren't limited to one active per channel like IDE is, thats the biggest advantage of the protocol. >>



Really? How does this work exactly? I don't see how one device can be transmitting at the same time as another. Their signals should "collide" and the resulting signals would be unintelligible to the controller.

 

[xerich]

SCSI offers queuing that allows full utilization of the bus, other interfaces like IDE or EIDE each
transaction must complete before the next one can be started. This often includes the time for the
head position and rotational latency. SCSI allows queuing of several commands to one or more
drives. The disk reorders the queue to take maximum advantage of the mechanical movements. The
SCSI devices usually use larger cache memories, which allows the bus to be used as close as possible
to the maximum bandwidth.

found this paragraph in a white paper on www.scsita.org

 

[Kostya17]

Kinda related to the topic--real-life performance of SCSI vs. IDE. I got 6400 CowBox thanx to "Hot Deals" forum. It has U160 controller/IBM 9.1GB HD. Added Quantum 40 GB 7200RPM HD/Ultra100 card. Now funny part: according to Nero HDSpeed (comes with Nero Burning Rom) SCSI has 12 MB/s, IDE 35 MB/s sustained speed. Go figure

My friend (senior EE Engineer) commented: "What do you expect? With all the additional overhead from SCSI queuing you're lucky you got 12 MB/s" :Q

Well guys, do you know where to get wares HD benchmark? I still don't believe IDE is faster...

 

[Nothinman]

SCSI devices can queue many commands, number depends on the controller and device, and reorder them for efficiency, also a device can 'disconnect' from the SCSI bus while it's doing this meaning any other SCSI device can be given commands while the others are processing the ones they have queued. This is why SCSI can handle so many more devices per chain than IDE and still out perform it, and why 15 SCSI devices on one chain in RAID is a good thing while >1 IDE devices on a chain in RAID is usually a bad thing.

 

[CQuinn]

Kostya17,

I think your EE friend is overlooking a few possibilities. (that's putting it nicely).

That IBM 9.1GB HD is probably an older model 7200rpm drive itself. It probably has a density of about 2Gig per platter,
where the Quantum is probably closer to 10Gig per platter.
Which means that the heads on the Quantum have to move 1/5th the distance to read back a given amount of data
during a sustained transfer.
That alone would give the Quantum a higher STR, but the IBM would probably still win out on a measure of access times,
which would make it a better boot drive for the server it was designed to work with.

The "additional overhead from SCSI queuing " would be negligble, as you only have the single SCSI drive to contend with.
Another factor to consider is whether the drive is running in LVD or SE mode (most likely Single Ended - SE). Modern
SCSI drives need to be able to run in LVD mode to take full advantage of the bandwidth on the bus, otherwise it is
limited to around ATA33/66 levels of performance.

Also, being able to put in a 10000 - 15000rpm SCSI drive in place of the IBM is a factor that would certainly win out,
which is also an feature that subflava overlooks in his early analysis... the faster drives can maintain a much higher STR,
along with the bus needing to also handle the burst transfers from the drive cache overall.

 

[Kostya17]

CQuinn,

thanx for explanations. IBM SCSI that I have is Utrastar 36LP, 3 surfaces, about 3 GB per surface. Maxtor (former Quantum) is Fireball Plus AS, which is 10 GB per surface. They are both 7200 RPM. So, following your input, Maxtor should be 10/3 = 3.333 times faster than IBM drive. According to Nero, it is 35/12 times faster, which is pretty close. You're right, IBM catches-up a little bit due to its faster seek time.

Stil, it's hard to belive that consumer-oriented Maxtor drive is faster than hi-end server drive from IBM. On the other hand, my modest "family sedan" is faster than many racing cars from 1950s

Anybody got a link to warez HD speed test? I stil think Nero HD Speed is incorrect...

 

[Richard98]

You may want to test the drives with winbench. It's more of an applications benchmarking program. Hdtach reported that my Maxtor ATA100 7200 rpm has a transfer rate of almost double my Atlas SCSI 10k iii. Winbench showed that the Atlas is actually much faster running real applications.

 

[Halz]

Agreed. HDTach is rather poor at benchmarking SCSI disks.. I built a 5 disk RAID-0 array on a Dell 2550 to throw at some bechmarks, HDTach one of them. For fun picture

Edit: Mind you, these are 10krpm 36GB IBM drives.. Ultra160, no less

 

[subflava]

Hmm...perhaps I didn't make my question clear and maybe the title of this thread is a bit misleading. I'm not really asking about the advantages of SCSI over IDE, etc. I'll assume we all know about the advantages and features that SCSI offers over IDE.

My question might be better stated this way: How can a data bus with a max transfer rate of 160MB/s, with individual devices capable of no more than 30MB/s, end up "filling" that data bus up to its theoretical limit assuming that only one devcie can actually be transmitting data at any given point in time?

I think a couple of you might have hit on something though. I believe the answer lies in the data buffers that all modern drives have now. It must be that while one drive is actively transferring data on the bus, the other drives can be busy filling their buffers with data while they "wait their turn". Once the first drive finishes its transfer then the next drive in line should already have data in waiting in its buffers. Since the transfer rate from drive buffer to the SCSI controller *is* capable of 160MB/s, that seems to be the answer to the question.

So as long as the other devices can keep their data buffers full while they are waiting to transmit, the bus can operate at nearly 100%. I believe the question has been answered.

 

[Peter]

The drive does bus-buffer and buffer-media transfers asynchronously. On writes to media, the bus-buffer transfer is completed at the interface rate of 160 MB/s,
and at the same time the buffer-to-media transfer gets started at a slower rate.

When the buffer gets full, SCSI drives disconnect from the bus to make it available for other devices, and comes back on its
own behalf for the next chunk. An IDE drive in the same situation holds the bus idle.

On reads, the flow just reverses - the read request comes in, the SCSI drive disconnects and the IDE drive holds the bus idle while
the media-to-buffer transfer starts.
When enough data have accumulated, the SCSI drives reselects the bus, does a first chunk of the buffer-to-bus transfer, and disconnects
again when the buffer empties. IDE drives just transfer a chunk and then hold the bus idle again. Repeat until complete.

Bottom line is, do a sustained transfer to/from an IDE drive (no matter what speed it is!), and your IDE channel is occupied 100 percent.
Doing the same on a SCSI channel occupies just a fraction of total SCSI bus time - the drive's physical media rate divided by
the bus interface rate (plus some overhead).

About IDE drives being faster because of that command overhead ... this does matter on very small transfer sizes, but with modern
operating systems that do their own buffering in system main memory these rarely happen anymore.

regards, Peter

 

[Peter]

Regarding the actual throughputs of that IBM drive vs. that Quantum ... that shows how fast the HDD industry moves
in terms of linear recording density. This areal density multiplied by the rotational speed is what dictates the media transfer rate.

http://www.storage.ibm.com/hdd/ultra/36lpdata.htm
C:\Downloads\maxtor\Fireball_Plus_AS_Product_Manual.pdf

IBM Ultrastar 36LP (DPSS) series media are 3 GBytes per surface, throughput at 7200 rpm is 248 on the inner tracks to 400 MBit/s on the outside (19.5 to 31.9 MByte/s),
this exactly matches what I personally measured a while ago.

Quantum's drive in turn has 10 GBytes per surface, at the same rpm one should think that means three times the transfer rate,
but we have an increased track density here, not so much an increased linear density.

IBM DPSS recording density is 350,000 bpi, track density is 18,400 tpi.
Quantum FB AS recording density is 442,000 bpi, track density is 35,799 tpi.

Quantum says sustained media transfer goes up to 471 MBit/s. One should think you shouldn't compare old drives with new ones,
but the actual speed difference on linear reads is just twenty percent or so despite the tripled per-surface capacity. (Besides, IBM's
DPSS series are low-end drives.)

Now why does Nero report such a drastic difference? Maybe the SCSI controller isn't very good, or the file system on the drive
needs defragmenting, someone forgot to enable sync transfers and write caching on the drive, or maybe Kostya's operating system sucks. DOS-based Windows 9x/ME isn't very good at handling multiplie
storage controllers, the further down in the list the controller is the slower it gets.

regards, Peter

 

[Kostya17]

Peter: I couldn't agree more--Win2K _SUCKS_
Others: I am downloading winbench... hoping to get some numbers tonight.

My setup: 6400 cowbox from Gateway (thanx to "Hot Deals" forum)
Mobo: ASUS CUR-DLS
SCSI: built-in LSI Ultra160/Ultra2 SCSI with single IBM drive. It is the one and only SCSI device in the system (not counting controller, of course ;-).
IDE: Maxtor UltraATA100 card (looks like rebadged Promise) with single Fireball Plus AS on channel 0 and single HP9900 (that "Hot Deals" forum again) on channel 1; both are "masters".

If you have suggestions on what could be messed up there--your comments are welcome. It's kinda strange that IDE is faster than Ultra160 SCSI. I'll post winbench numbers as soon as I get 'em.

 

[Peter]

OK, we're getting somewhere. LSI's SCSI engine is a very good and very speedy RISC one. Check the following: Is LSI's own "high performance" SCSI driver installed, or W2K's own generic one that doesn't use the optimized command set in the U2W and U160 controller chips. Then check whether the drive itself is configured to use its write cache - from DOS, use Seagate's ASPI-WC.EXE (don't worry, SCSI-2 drives all work the same in configuring this). Then see whether the drive has its "Force SE" jumper set. If so, put it off to get the thing into LVD mode. And then finally, see in the controller's own setup whether the entire channel or this particular drive's interface throughput is configured to full speed or something lower.

With all that stuff sorted, that IBM drive should be no more than 20 percent slower than that technically much newer Quantum thing.

Rules of SCSI, #1: SCSI wants perfect setup work, the slightest mistake WILL show. If you get it right, you'll never get any troubles later.

regards, Peter

 

[Kostya17]

Peter,

thanks for the info. I use LSI SCSI drivers. Is ASPI-WC.EXE available from Seagate web cite? Or I need to hunt it down in hackers' forums?

 

[Peter]

Yes, that utility is buried somewhere on Seagate's site.

 

[Kostya17]

Winbench 99, High-End Disk Winmark 99
IDE: 22.6 MB/s
SCSI: 12.9 MB/s

 

[Peter]

Still seriously fishy, that drive should be performing much better. So did you check all the other stuff I told you? Visit the LSI SDMS configuration (press Ctrl-C when prompted on the POST screen) to see whether the channel is set to U160 at all.

Once all is set, you should measure raw drive throughput using HDTach or something. If that's OK, and file system throughput still sucks, then it's the file system that doesn't cut it.

regards, Peter

 

[ucla88]

<< assuming that only one devcie can actually be transmitting data at any given point in time? >>






<< Really? How does this work exactly? I don't see how one device can be transmitting at the same time as another. Their signals should "collide" and the resulting signals would be unintelligible to the controller >>



their are many ways to multiplex signals so that multiple datastreams can be fed over the same cable. look at ethernet, for example.

 

[Kostya17]

Peter,
LSI SDMS configuration was the problem. HD auto-detects SCSI speed as "NO" (WTF is that?). When corrected to "160" the High-End Disk Winmark 99 went up to 19.1 MB/s and Nero HDSpeed is now 25 MB/s. Thanks, wiz!

P.S. Is there anything like "SCSI for Dummies" around 'net? I gonna need that

 

[Peter]

Ah, so synchronous operation was disabled on that drive (or on the entire channel?).

What you adjust in SDMS setup is the maximum synchronous transfer speed that is allowed during
transfer speed negotiation. It goes like this, the host controller suggests its top speed (that adjustable
one) to each drive, and the drive responds with either that or a lower speed if it can't go that fast.

So if you limit the host's suggestion to lowest possible, then you're at stoneage async transfer
mode, which, on a wide cable, is exactly 12 MB/s.

Normally, you leave that setting for all drives and channels at its best. Manual interception is only
required for single drives that claim support for faster bus modes than they actually have (which would
then be a drive firmware bug), or for an entire channel when your cables get too long for a certain mode (which often
happens with single-ended ultra SCSI when external devices are added).
(And while you're at it, are the Disconnect and Tagged Queuing features enabled?)

SCSI for dummies? don't know of any book like this ... Unix magazines do that routinely however.

regards, Peter

PS: Would you please go kick that clueless, SCSI-bashing senior EE for me?

 

[Peter]

ucla and others, there is no multiplexing going on with SCSI.
It's just asynchronous and queued completion of tasks. Combined with high interface rates, this allows one
drive to release the bus for use with other devices while it works on completing one or more requests.
So a data transfer actually uses as much interface time as the amount divided by the _interface_ speed
would suggest.
IDE doesn't have that, so the interface channel is blocked longer - amount divided by the _media_ speed.

The outcome is that you get much more free channel time with SCSI, which makes multiple drives
work quite a lot better.

regards, Peter

 

[ucla88]

 

[ucla88]

wow, i was momentarily speechless



<< ucla and others, there is no multiplexing going on with SCSI. >>



peter

scsi transfer is synchonous.

in a general sense multiple signals sharing the same line on a synchronous bus can be considered a form of time division multiplexing at least conceptually, even though it's not generally thought of in this way.