IDE/SCSI bus transfer rates

[ucla88]

course you know that synchronous/asych-belatedly read your other posts.

never mind

 

[ucla88]

again to go back to the original question that subflava posted. it seems that you're having a bit of difficulty grasping the concept that multiple devices can share the bus concurrently. now, before we get into arguements about concurrency, multiplexing, synch v asynch, burst, consider the following analogy.

i am running a train depot where we load shipments onto a train (the bus). let's say the train is moving at a speed (conceptually, it's clock rate) such that 4 empty traincars pass by my loading dock every minute. my job is to load cement bags onto the traincars. the best i can do is 40 bags per forklift run every minute. so what happens, every minute i load 40 bags onto one boxcar. i'm going as fast as i can, but still, 3 cars go empty in the time it takes me to load my 40 bags. the boss, seeing the waste, sets up 3 other loading areas, each with their own person/forklift. now we have 4 people going full speed loading 4x40=160 bags per minute.

you get the idea now4 40Mb/s devices on a U160 chain, blah, blah...

what you should check out is pcguide.com or techfest.com and read about bus architecture in general, whether it's pci,scsi, ide


p.s. is this multiplexing? it can be thought of as such conceptually-multiple information streams carried over a single line or set of lines.

 

[Richard98]

Good analogy. Another one I read recently is retrieving books at the library - :

Radified Guide to SCSI

 

[Peter]

ucla, two things can be sync or async here. Let's keep them apart.

The transfer itself can be synchronous or asynchronous, as demonstrated by Kostya Here, you want sync for maximum transfer speed.

The completing of commands can be synchronous or asynchronous, with synchronous completion blocking the channel until the actual media gets the stuff done (just like with IDE), while asynchronous completion (using SCSI features Disconnect/Reselect and Tagged Command Queuing) saves precious channel bandwidth by releasing the bus to others inbetween transfer bursts. That's what I'm talking about all the time.

So for best performance, you want synchronous transfer modes and asynchronous command completion.

regards, Peter

 

[ucla88]

you're quite right peter. my post above was kind of an apology, but in rereading it, it may not have sounded that way.

 

[Kostya17]

And while you're at it, are the Disconnect and Tagged Queuing features enabled?
Will check it tonight... But do these features matter for a single SCSI drive? Another question: how do I enable write caching?
Thank you for your help.

P.S. Would you please go kick that clueless, SCSI-bashing senior EE for me?
Sure! Gonna meet him this weekend to upgrade firmwire of Apex 500W. We'll have a talk on SCSI vs. IDE.

P.P.S. Looks like this forum's name should be changed to "SCSI FAQ"

 

[Peter]

Hi again folks.

ucla88, no offense taken, just trying to make sure everyone's got it right.

kostya, yes, disconnect/reselect and Tagged Queuing do matter with a single drive.
With these features enabled, the drive can accept a command and release the bus,
and while working on the result, accept more commands from the host. It can then
sort the queued requests to optimize completion time (will say, complete the requests
in an order that minimizes on rotational latency and head movement), and even return
the results in a different order (with the ID tag of the original request on, hence the name).

The drive's write caching is checked and enabled using that ASPI-WC.EXE, remember?

regards, Peter