> few questions before i do though. how does scsi compare to ata 133 and usb 2.0
> for cdrw drives and hard drives?
SCSI or at least U80/U160 will outperform these two with "half the power" USB is
thought for maximum connectivity and still very slow. Go for Firewire if it
really needs to be an external drive.
ATA 133 is just one more extension of the more and more saturated ATA Standards
(33->66->100->133 .... 150 != max ?), and allowes you to use drives above 128
GB, the advantage in speed compared to UDMA-100 is more literally, as there
exist no hd`s that fast for ATA and it is no good advice to attach more than one
device to one ATA channel, if you go for performance (although master/slave
combinations are possible).
If you are planning to have a little workstation or so, it might be a nice thing
to have a fast and "small" (about 20 GB) U160 drive for you OS because of
superior seek/access times and the better handling of I/O´s of the SCSI Bus and
the data on an ATA raid or so. This might be also pretty cheep, ATA storage is
"almost for free" these days :-D
If you are just going for a fast Windows XP desktop with one or two hd`s, and
you average I/O maximum is during the boot :) .... you´ll be fine with a ATA 133
drive, and you´ll save a lot of money !
> i see that plextor has a 12X scsi drive and a 40X usb 2.0 drive.
The result of a stupid development of the market, since SCSI drives are no more
developed (IMO). btw ... I know that Plextor has 40x SCSI drives for about 3
years now, as I have some of these .... did you mean CD drive or CD writer ?
Then the answer would be : it is easy to built a USB to ATA converter and they
take one, and attack simply their 40x ATA writer device, and claim that this
thing will "be able" (in theory *BG*) to write 40x..... to me it is more a
"earth is flat" argument :)
> [...] but wouldnt it even out at udma 133? as you can see, im confused about
> all this, if this has been addressed already or is answered in the FAQ, please
> point it out to me. thanks all.
160 MB/s or 133 MB/s is just the theoretical performance peak of raw data on the
bus. It has very few to say actually on how well the storage subsystem will
perform. This depends more to your hd`s and their specs. It is almost impossible
for one drive to permanently saturate an U80 oder UDMA-66 bus. UDMA-133 is as I
already said more important if you are planning to use drives above 128 GB,
although there already exist some patches to enable the adress extensions for
UDAM-100 controllers, too.
HTH Daniel
"The Fueley" <CRi...@gci.net> wrote in message
news:ui4m4h8...@corp.supernews.com...
Use SCSI if you have lots of devices, or want the best
performance you can get. SCSI is significantly more
expensive than IDE.
"Daniel Hojka" <dr...@sbox.tugraz.at> wrote in message news:3D22A1DD...@sbox.tugraz.at...
The Fueley wrote:
> few questions before i do though. how does scsi compare to ata 133 and usb 2.0
> for cdrw drives and hard drives?
SCSI or at least U80/U160 will outperform these two with "half the power" USB is
thought for maximum connectivity and still very slow.
Whatever that is supposed to mean.
Go for Firewire if it really needs to be an external drive.
ATA 133 is just one more extension of the more and more saturated ATA Standards
(33->66->100->133 .... 150 != max ?), and allowes you to use drives above 128GB,
Nope.
the advantage in speed compared to UDMA-100 is more literally, as there
exist no hd`s that fast for ATA and it is no good advice to attach more than one
device to one ATA channel, if you go for performance (although master/slave
combinations are possible).
Works fine for sequential transfers, less so for random access.
Nope.
although there already exist some patches to enable the adress extensions for
UDAM-100 controllers, too.
Exactly. Nothing to do with ATA133
HTH Daniel
> please turn off Quoted Printable
Just for you :))
> > few questions before i do though. how does scsi compare to ata
> > 133 and usb 2.0 for cdrw drives and hard drives?
>
> > with "half the power" USB is thought for maximum connectivity
> > and still very slow.
>
> Whatever that is supposed to mean.
What could it mean ?
> > ATA 133 is just one more extension of the more and more
> > saturated ATA Standards (33->66->100->133 .... 150 != max ?),
> > and allowes you to use drives above 128GB,
>
> Nope.
I hope the "nope" was for 150 != max ... else please read below.
> > device to one ATA channel, if you go for performance (although
> > master/slave combinations are possible).
>
> Works fine for sequential transfers, less so for random access.
Ah, I didn`t know that ... thx, one more dead prejudice.
> Nope.
If I may quote maxtors statement to ATA 133 :
"[...] leading the industry effort to move to capacities up to 144
petabytes (PB), Maxtor has helped lay the foundation for future
storage technologies," said Ted Deffenbaugh, vice president of
product strategy for Maxtor. "By supporting the standard, which we
have submitted to the ANSI T13 committee"
and :
"initiative succeeds in breaking through the barrier with an upgraded
ATA interface allowing for up to 48 bits of address space on a
single drive, and therefore the maximum capacity of an ATA device up
to 144PB"
Same but a bit more specific is t13.org, and if someone knows something
about ATA ...
> Exactly. Nothing to do with ATA133
Until now, I didn`t have the honour to learn more about the protocol
or exact adressing in ATA, but a patch is a patch, is a patch :)
I have no idea how these patches work, but they must somehow extend
the adressing.
If I am wrong in some points, please feel free to correct me.
Regards,
Daniel
"Surpassing the 137GB limit is another notch in the evolution of
storage capacity. We are very pleased to be working with Maxtor to
enable increased capacity for our mutual customers,"
Regards,
Daniel
You tell us.
>
> > > ATA 133 is just one more extension of the more and more
> > > saturated ATA Standards (33->66->100->133 .... 150 != max ?),
> > > and allowes you to use drives above 128GB,
> >
> > Nope.
>
> I hope the "nope" was for 150 != max ... else please read below.
No, as should have been apparent from my last comment.
ATA133 has nothing to do with 48-bit LBA addressing.
48-bit LBA addressing is an ATA/ATAPI-6 feature while UDMA
mode 6 (ATA133) is still not mentioned even in ATA/ATAPI-7.
>
> > > device to one ATA channel, if you go for performance (although
> > > master/slave combinations are possible).
> >
> > Works fine for sequential transfers, less so for random access.
>
> Ah, I didn`t know that ... thx, one more dead prejudice.
>
> > Nope.
>
> If I may quote maxtors statement to ATA 133 :
>
> "[...] leading the industry effort to move to capacities up to 144
> petabytes (PB), Maxtor has helped lay the foundation for future
> storage technologies," said Ted Deffenbaugh, vice president of
> product strategy for Maxtor. "By supporting the standard, which we
> have submitted to the ANSI T13 committee"
>
> and :
>
> "initiative succeeds in breaking through the barrier with an upgraded
> ATA interface allowing for up to 48 bits of address space on a
> single drive, and therefore the maximum capacity of an ATA device up
> to 144PB"
Well , that is MAXTOR. They chose to start both at the same
time but they still divided them into Big Drives and Fast Drives.
(Big = >137GB, Fast = ATA133)
>
> Same but a bit more specific is t13.org, and if someone knows something
> about ATA ...
Yes, try and find ATA133 there. Goodluck.
>
> > Exactly. Nothing to do with ATA133
>
> Until now, I didn`t have the honour to learn more about the protocol
> or exact adressing in ATA, but a patch is a patch, is a patch :)
> I have no idea how these patches work, but they must somehow extend
> the adressing.
Yes, like every update did that overcame any former capacity limitations.
The 48-bit LBA support is a bit closer to the actual hardware so it may be
a bit more difficult to get updates or workarounds like the EZbios kind
but it is still a software change so can be applied to all previous hardware.
> > What could it mean ?
> You tell us.
Ok, I`ll tell you ... the topic of this thread is "SCSI vs ATA 133
vs USB 2.0" ... well IMO the "vs" is read as "versus", which again
adds some kind of competitive component to the question ...
So, to keep it simple and to avoid more fuzzyness, I he asked what
is best, and I told him, what would be the best from my point of
view.
> ATA133 has nothing to do with 48-bit LBA addressing.
> 48-bit LBA addressing is an ATA/ATAPI-6 feature while UDMA
> mode 6 (ATA133) is still not mentioned even in ATA/ATAPI-7.
> [...]
> Well , that is MAXTOR. They chose to start both at the same
> time but they still divided them into Big Drives and Fast
> Drives. (Big = >137GB, Fast = ATA133)
Ok, in the meantime I think you were absolutely right
seperating the two techniques from each other. Sadly Maxtor was
one of the first, if not the first to introduce the ATA-133
interface, and to me it seems they wanted to put the extended LBA
and enhanced performance together.
So, I guess I should have read the off. specs instead of such "AOL
invented mail and the internet"- announcements.
> Yes, try and find ATA133 there. Goodluck.
They included a proposal for UDMA-133 in here :
http://www.t13.org/docs2002/d1532v1r0b.pdf
"Added e01135r1 UMDA 133 as approved at the February 2002
plenary."
There`s also an article about the 48 bit feature set, I`ll
read it ASAP :)
> Yes, like every update did that overcame any former
> capacity limitations. The 48-bit LBA support is a bit
> closer to the actual hardware so it may [...]
Thanks for clearing that up.
Kind regards,
Daniel
Yes, but what about that part that you conveniently snipped:
> > > with "half the power" USB is thought for maximum connectivity
> > > and still very slow.
So, what's this fuzzy "half the power" thing ?
>
> > ATA133 has nothing to do with 48-bit LBA addressing.
> > 48-bit LBA addressing is an ATA/ATAPI-6 feature while UDMA
> > mode 6 (ATA133) is still not mentioned even in ATA/ATAPI-7.
> > [...]
> > Well , that is MAXTOR. They chose to start both at the same
> > time but they still divided them into Big Drives and Fast
> > Drives. (Big = >137GB, Fast = ATA133)
>
> Ok, in the meantime I think you were absolutely right
> seperating the two techniques from each other. Sadly Maxtor was
> one of the first, if not the first to introduce the ATA-133
> interface, and to me it seems they wanted to put the extended LBA
> and enhanced performance together.
> So, I guess I should have read the off. specs instead of such "AOL
> invented mail and the internet"- announcements.
>
> > Yes, try and find ATA133 there. Goodluck.
>
> They included a proposal for UDMA-133 in here :
>
> http://www.t13.org/docs2002/d1532v1r0b.pdf
Ah, my mistake. Apparently there are new versions out, I should have checked.
It wasn't yet in the version I downloaded only a couple of months or so ago:
d1532v1r0.pdf
>
> "Added e01135r1 UMDA 133 as approved at the February 2002
> plenary."
>
> There`s also an article about the 48 bit feature set, I`ll
> read it ASAP :)
48-bit apparently, was first added to rev0b of ata/atapi-6 in october 2000.
"Timothy A. Seufert" <t...@mindspring.com> wrote in message
news:tas-099BA1.1...@netnews.attbi.com...
|
| During PIO, the controller is simply a dumb conduit for read and write
| operations performed by the CPU, so LBA48 can be made to work in PIO no
| matter how old the controller -- it's all done in software. But my
| understanding is that in DMA modes, the controller plays a role in
| sending ATA commands to the device, and some older controllers are
| simply incapable of double pumping the device's address register (or
| have some level of bugginess when doing so).
|
My point is still valid, with either mode of transfer the control registers
are accessed with PIO. Have you ever read the PIIX/ICH spec sheets?
"Timothy A. Seufert" <t...@mindspring.com> wrote in message
news:tas-9F61BD.0...@netnews.attbi.com...
| >
| > Nope. The control registers are always PIO, the data register is unused
during
| > DMA transfers.
|
| A. Please do not top post. It makes you look like a dork on Usenet.
| I've reformatted things to give you the right idea.
|
| B. Tell that to the people who actually have to write ATA device drivers:
|
| http://marc.theaimsgroup.com/?l=linux-kernel&m=101992286008703&w=2
|
| --
| Tim
Don't have to guess what the response to that one will be.
No doubt something about specific newsgroup trolls and OS zealots.
Far more people are annoyed by people like you.
"Timothy A. Seufert" <t...@mindspring.com> wrote in message
news:tas-07A9DF.0...@netnews.attbi.com...
| In article <ags94...@enews4.newsguy.com>,
| "Eric Gisin" <er...@netidea.com> wrote:
|
| > Please do not tell people how to post. It makes you look like a Troll.
|
| Please do not top post. I'm telling you this for your own good. It
| makes you look like a rude dork. This has nothing to do with trolling,
| and everything to do with simple courtesies that make reading threaded
| Usenet discussions easier.
: Please do not top post. I'm telling you this for your own good.
Like he did it for your own good. It appears we have a standoff.
: It makes you look like a rude dork. This has nothing to do with trolling,
: and everything to do with simple courtesies that make reading threaded
: Usenet discussions easier.
Exactly, which is why he topposts. You are only following rules even if it
conflicts with why you say you are following them. That makes you a zealot.
:
: > My point is still valid, with either mode of transfer the control registers
: > are accessed with PIO. Have you ever read the PIIX/ICH spec sheets?
:
: Not before now. You are probably right; I merely assumed that since
: some controllers do have problems with LBA48 when using DMA, DMA must
: have been involved in accessing the control registers.
:
: Which brings us back to the beginning: some ATA controllers fail to work
: correctly when you mix DMA and LBA48, regardless of how good I am at
: guessing the reason why. Most are fine, but there are exceptions.
:
: --
: Tim