Bus Mastering vs. different IDE channels

  • Thread starter Thread starter Timothy Daniels
  • Start date Start date
T

Timothy Daniels

drumguy1384 said:
From the article you posted a link to on IDE Bus Mastering:

"Bus Mastering Hard Disk: Normally this means that the drive must
be capable of at least multiword DMA mode 2 transfers. All Ultra
ATA hard disks also support bus mastering."

Also, from that same article:

"Bus mastering IDE will not help at all in the following situations:

* It will not make that 100 MB transfer from C: to D: that you are
sitting and watching go much faster at all.
* It will not speed up DOS games.
* It will not make applications load more quickly (unless you
somehow are loading more than one at a time).
* It will not speed up single applications."

This article, however, was written when Windows 95 was the premiere
OS for the PC (not a true multi-tasking OS) ... it is quite possible that
IDE bus mastering has been improved on in the time since then. However,
aside from higher speeds, IDE drives have not changed much, nor has
the PCI bus.

Also, you can rest assured that the Promise and SIIG controllers will
do bus mastering. The UATA spec requires it. That's why Dell reported
their controllers "ATA spec compliant."

In fact, I have a SiS UATA133 RAID controller that would not detect the
drives connected to it at all until I enabled "external PCI controller bus
mastering" in the BIOS.

Hope this can shed some more light.


My 2 hard disks certainly support bus mastering - they're both
Ultra ATA 133 and the same model made by the same manu-
facturer. The Dell chipset and BIOS support bus mastering in
support of ATA 33. And the Promise and SIIG Ultra ATA 133
expansion cards support bus mastering. The OS is WinXP Pro.
It sounds like everything is a go for bus mastering for both the 2
hard drives (attached to the expansion card) and the optical devices
hooked to the legacy ATA 33 bus. It may be insignificant in effect,
but bus mastering caught my attention because I felt it might
compensate for putting both hard drives on the same IDE channel
rather than give each its own dedicated IDE channel in the interest
of fast hard drive-to-hard drive volume imaging. What do you think?
If 2 HDs on the same channel could transfer data directly from one
to the other via bus mastering, might it be faster than HDs on 2
channels
that have to transfer data to and from a RAM buffer on the expansion
card or in main memory in order to transfer data from one to the other?
In other words, given 2 modern HDs in a bus mastering enabled
environment, would HD-to-HD data transfers go faster if they're put
on different channels or on the same channel?


*TimDaniels*
 
Timothy Daniels said:
My 2 hard disks certainly support bus mastering - they're both
Ultra ATA 133 and the same model made by the same manu-
facturer. The Dell chipset and BIOS support bus mastering in
support of ATA 33. And the Promise and SIIG Ultra ATA 133
expansion cards support bus mastering. The OS is WinXP Pro.
It sounds like everything is a go for bus mastering for both the 2
hard drives (attached to the expansion card) and the optical devices
hooked to the legacy ATA 33 bus. It may be insignificant in effect,
but bus mastering caught my attention because I felt it might
compensate for putting both hard drives on the same IDE channel
rather than give each its own dedicated IDE channel in the interest
of fast hard drive-to-hard drive volume imaging. What do you think?
If 2 HDs on the same channel could transfer data directly from one
to the other via bus mastering, might it be faster than HDs on 2
channels
that have to transfer data to and from a RAM buffer on the expansion
card or in main memory in order to transfer data from one to the other?
In other words, given 2 modern HDs in a bus mastering enabled
environment, would HD-to-HD data transfers go faster if they're put
on different channels or on the same channel?


*TimDaniels*

As I've thought about it, and refreshed my memory I don't really think that
bus mastering will increase the speed of transfer between your drives ...
not as long as they are connected to the same port anyway.

Bus mastering allows a device to take over or "master" the bus (the PCI bus,
that is) if it needs it. This can make things operate more smoothly in a
multi-tasking environment. But you have to remember that you are still
dealing with only one IDE controller port.

Yes, the controller itself can "master" the bus, and because of UATA it can
also do DMA (Direct Memory Access) which means that the drive can dump data
to the memory without troubling the processor, which can also increase
performance.

None of this, however, allows the drives to talk directly to one another and
transfer data completely independently of the rest of the system. They will
still have to use a RAM buffer no matter what.

Using separate ports, however, the controller can simultaneously read from
one drive while writing to the other ... facilitating basically the same
thing as one drive speaking directly to the other. This is why it is
*always* better to have your drives on separate ports. This is the fastest
configuration.

It sounds like you have enough ports to do it this way. Use the two ATA33
ports on the mobo for your optical drives, and give each of your hard drives
a separate port on your PCI controller card. This will work the best ... for
hard drive performance anyway ... your optical drives might possibly benefit
from the increased speed of the add-in card, but probably not.

I also might suggest that you go with round IDE cables ... I run a RAID
array with two 80gig drives, each on their own port (on a RAID expansion
card), as well as a DVD-ROM and CD-RW, each with their own port (on the
mobo). Add in a floppy cable and it gets a little hard for the air to move
around in there because of all the ribbon cables (5 total) obstructing the
air-flow. I lowered both my internal ambient temperature as well as my
processor temperature significantly by switching to round cables.

Drumguy
 
Timothy Daniels said:
My 2 hard disks certainly support bus mastering - they're both
Ultra ATA 133 and the same model made by the same manu-
facturer. The Dell chipset and BIOS support bus mastering in
support of ATA 33. And the Promise and SIIG Ultra ATA 133
expansion cards support bus mastering. The OS is WinXP Pro.
It sounds like everything is a go for bus mastering for both the 2
hard drives (attached to the expansion card) and the optical devices
hooked to the legacy ATA 33 bus. It may be insignificant in effect,
but bus mastering caught my attention because I felt it might
compensate for putting both hard drives on the same IDE channel
rather than give each its own dedicated IDE channel in the interest
of fast hard drive-to-hard drive volume imaging. What do you think?

That you're getting FAR too anal.

Why dont you actually try the two configs, both on the one
ribbon cable and each on a separate ribbon cable and see
if you get any real improvement in the speed of ops where
you are sitting in front of the PC waiting for it to happen ?

If you do crude image backups much, try that too, but bear in
mind that if you have any sense you wont normally sit around
twiddling your thumbs in front of the PC waiting for the image
creation to happen, so even if you can see a small speedup with
the creation of a compressed image, its completely academic.
If 2 HDs on the same channel could transfer data
directly from one to the other via bus mastering,

You're getting completely confused here too. The
short story is that as long as you have DMA enabled
and in use, thats all that matters with modern hard
drives and motherboards and IDE controller cards.
might it be faster than HDs on 2 channels
that have to transfer data to and from a RAM buffer on the expansion
card or in main memory in order to transfer data from one to the other?

Nope, the problem is the theoretical simultaneous access to
both drives at once. Since both drives on the same ribbon
cable cant be SIMULTANEOUSLY reading on one and
writing on the other, in theory that config will be slower.

In practice apps like Ghost dont actually attempt to
read on one and write on the other literally simultaneously
anyway. They read from one into memory, then write
from memory onto the other when creating an image file.
With quite a bit of time taken to compress the image file.
In other words, given 2 modern HDs in a bus mastering enabled
environment, would HD-to-HD data transfers go faster if they're
put on different channels or on the same channel?

Separate channels will ALWAYS be theoretically faster just
because you can literally simultaneously read off one and
write on the other drive. BUT in practice very few apps actually
do that in practice, so the difference is very theoretical in practice.

And its a rare app that would even benefit from that possibility
in the real world with modern desktop systems anyway. And
what few there are that could theoretically benefit, arent normally
used with the user sitting in front of the PC twiddling his thumbs
waiting for the op to happen with a modern desktop PC.
 
Rod Speed said:
what few there are that could theoretically benefit, arent normally
used with the user sitting in front of the PC twiddling his thumbs
waiting for the op to happen with a modern desktop PC.

You just don't love your pc enough to watch! You're not one of us!
 
"drumguy1384" crunched the options:>
What exactly do you plan on using the removable drive for?
Because of physical placement issues it's not going to be able
to be slaved to either of the internal drives. It will either have
to go on a port with one of the CD drives or on it's own port
on the expansion card with both of the internal HDDs sharing
the other port. Another option would be to group the CD
drives together and give the removable HDD the free port on
the mobo.

If it's just going to be used for occasional backups (that could
be automated to operate while you're sleeping) it might be a
good idea to put it as master on the same port as your least
used CD drive or put the CD drives together and put it on
it's own port on the mobo, because the slower speed would
not cause an issue. But if performance on that drive is a must
then you might just give it it's own port on the ATA133 card
and group the two internals together. That would cause file
copies between the two internals to slow down, but would
greatly speed up the operation of the removable drive.

Truth is, for optimal transfer between all drives you would
need another expansion card so that each drive could have
it's own channel, but it is unlikely that you would need all of
that performance on all of your drives... at least not enough
to warrant the expense of another expansion card.

It seems a waste to put a modern HDD on an ATA33, but
in this instance it might be satisfactory ... depending on what
the drive is going to be used for.

It just depends on what you want to do with that removable
drive.


OK, here're the intimate details: I do a lot of compiling and
the resulting apps use a lot of runtime support (Java, C#, C++).
There are a lot of file reads and writes. I plan to use one hard
drive for WinXP Pro and the other for Linux, with perhaps a
NickLock for switching between one and the other as the
boot drive. Each drive will use a small partition on the other
for virtual memory (swap file/page file). That is why I want to
put each drive on its own channel. I plan to use the 3rd drive
for periodic backups of the images of the first 2 drives. The
backups don't need to be attended, but I still would like them
to complete quickly as possible.

It looks like I will just have to use one of the 2 Ultra ATA133
channels for the backup drive, putting it in a caddy that will fit
in the empty 5 1/2" bay. I plan to eventually go to an external
backup drive when FireWire 800 drives appear. Promise Tech
has already announced a FireWire 800 PCI expansion card,
and a FireWire 800 external drive should be fast enough for
backups.

The existing legacy IDE channels on the motherboard will
handle the optical and Zip drives. Each of the two optical
drives will be on different channels, one channel shared with
the Zip drive.

At least that's how I *currently* plan to configure the system.
:-)


*TimDaniels*
 
Rod Speed said:
Never been into that sort of perverted behaviour myself.


Thank 'god' for that.

Little do you know that the God Of PC's knows you scorn them while they're
crunching massive tasks.
 
Little do you know that the God Of PC's knows you
scorn them while they're crunching massive tasks.

Little do you stupid god botherers
know what that god thinks of you.
 
"Rod Speed" purred:>
Makes a hell of a lot more sense to just ensure plenty of
physical ram so you dont use the swap file much at all.

Physical ram will always be MUCH faster than any farting
around you could ever do with controllers and hard drives.


I'm currently maxed out on what Dell says is the max amount
for the system - 384G. I've read from several posters who
say twice the amount will work (768G) if I install the latest
BIOS - which I plan to do.

Pointless bothering.

Pointless anal if they aint attended.

And real backup as opposed to mindless image backup
of the entire drive will speed things up MUCH more too.

Complete waste of time/money.

And get to wear the deficiencys of those massive kludges.

The current firewire is perfectly adequate for that.

A standard firewire external is plenty fast enough for backups.

Mindlessly anal. Wont make a scrap of difference because
optical drives are MUCH slower than the channel bandwidth.

That piece of shit should be filed in
the round filing cabinet under the desk.

Guess you could well do without a vacuum cleaner.
You can just zoom around the floor on your arse instead |-)



Hee, hee. Your sweet nothings are always welcome, Rod.


*TimDaniels*
 
Timothy Daniels said:
Rod Speed wrote
I'm currently maxed out on what Dell says is the max
amount for the system - 384G. I've read from several
posters who say twice the amount will work (768G) if
I install the latest BIOS - which I plan to do.

Then there isnt any point in getting all anal about what drives
are on what controller to purportedly optimise swap file use.
 
Back
Top