Archived from groups: comp.sys.ibm.pc.hardware.storage (
More info?)
"Curious George" <CG@email.net> wrote in message news:vifqn0pjhrjrludj76h11eldb41a4s46rr@4ax.com
> On Mon, 25 Oct 2004 00:32:47 +0200, "Folkert Rienstra" <see_reply-to@myweb.nl> wrote:
> > "Curious George" <CG@email.net> wrote in message news:4j4kn09hgtviikvkgshbe9139r7tpv8r12@4ax.com
> > > On 23 Oct 2004 04:40:41 GMT, Arno Wagner <me@privacy.net> wrote:
> > > > Previously dg <dan_gus@hotmail.com> wrote:
> > > > >
http://channels.lockergnome.com/hardware/archives/20041019_first_hard_drive_with_30_gbs_serial_ata.phtml
> > > >
> > > > > I have always claimed that the whole Ultra ATA 66/100/133 is just a scam,
> > > > > as the interface is not the bottleneck. I get lots of people arguing with me
> > > > > about that, probably because they don't want to believe they were taken by
> > > > > the scam.
> > >
> > > The biggest problem is that many people think they are going to be
> > > reading & writing all their files at 66, 100, 133MB/sec.
> >
> > > It's misleading to naive users.
> >
> > Naive users mislead themselfs.
> > Thats probably why one calls them 'naive' in the first place.
>
> Its no secret the industry intentionally misleads buyers. You'll
> never see usefull/adequate performance information when you go to buy
> a new PC or from a disk manufacturer when you look up disk specs.
Well, that isn't exactly "intentional mislead".
Performance information isn't the same as specs, and specs is what they supply.
> Drive transfer rates, if available at all, tend to be buried in
> manufacturer specs, and like every other performance figure, the
> truth is stretched.
If you read the specification manuals for diskdrives you'll find that the
performance figures usually comply whith those from the storage sites.
> It takes quite a bit of sophistication to know what
> matters and what you need when it comes to performance attributes.
Right. It takes an un-naive look.
>
> > > So are disk capacities, CPU MHz, etc.
> > >
> > > > Depends. With two modern disks on one bus ATA 66 is the bottleneck.
> >
> > Only in RAID or with drives with a STR of over 60MB/s.
> >
> > >
> > > Doesn't it also depend on usage patterns?
> >
> > Access pattern. Yup.
> > But then for the time NOT spend in seeks, data is still transferred slower.
> > It depends on the proportion of seek vs transfer time how much impact that
> > will have on the average transfer rate.
>
> mentioned speed loss is the case of "RAID or with drives with a STR of
> over 60MB/s" on ATA-66 but not most scenarios and usage patterns of
> "two modern disks on one bus ATA 66."
Since an ATA bus has to support two devices simultaniously, yes,
an ATA66 bus will support a single ATA133 drive just fine.
I thought you were arguing that access pattern would destroy the
average STR and that a lower busspeed therefor would still suffice.
That is only partially true.
>
> The reality is that ATA 66 is fairly antiquated at this point and new
> ata controllers are very cheap. It's purely academic to talk about
> minor performance loss, or performance loss in a specific situation,
> when connecting the newest drive you can find to the oldest controller
> you can find. It's no secret that it is generally safe to assume that
> mixing very old with very new has the potential to be suboptimal.
>
> > >
> > > > Also ATA has the problem that switching from one disk to another on
> > > > the same bus is slow.
> > >
> > > But the UDMA spec is supposed to support multithreaded IO.
> >
> > There is no UDMA spec.
> > There is an ATA spec that started to cover Overlapped IO and Queueing.
>
> These features date back to ATA-ATAPI 4 which was dubbed "Ultra
> DMA/33." Subsequent PATA standards also have UDMA marketing names.
Not in this group.
>
> If memory serves, multithreaded IO was the term coined to describe a
> group of features whose net effect were what we are parsing words to
> try to describe.
>
> > > SATA doesn't have to deal with this (at least not per/channel).
> >
> > In theory. In practice this depends on the Host controller.
>
> Right, hence the caveat.
I think not. If the controller is a standard ATA controller
with sata->pata bridges added there is still the same problem.
>
> > > > > Anyway, a co-worker of mine was just telling me about an article
> > > > > he read about drives that have a 3Gbps transfer rate. Is this just
> > > > > another marketing scam? If so, this is just getting ridiculous!
> > > >
> > > > Well, the interface itself is cheap and whether it is 150MB/s or
> > > > 300MB.s does not really matter.
> >
> > Of course it does.
> > Technological progress has to be fought for and comes at a price.
>
> Fighting for technological progress by being an early adopter is
> fighting windmills.
>
> > The price has to suit the product or it won't be bought.
>
> And it has to seem shiny and new and either have more bells & whistles
> or seem like it could be faster than the next guy's product.
>
> > > > And if it is fast you will not have to re-design it every few years.
> >
> > Yet that is what you will be forced to do when technological progress
> > only allows you just so much and not more.
>
> But _when_ will this technological limitation come?
>
> Pushing technology is also part of how the business of technology
> (including marketing) is done. It is not a matter or pure engineering.
>
> Unless it is incredibly inefficient, or disk manufacturers make
> unprecedented strides, present SATA and SATA2 is in no imminent danger
> of being inadequate. Of course we all expect it will eventually.
>
> > > SATA only supports 1 drive/channel so the ceiling is significantly
> > > higher than PATA.
> >
> > Actually, that depends on protocoll overhead. We may have to wait to see
> > in practice how much that really is when the faster drives with SATA300
> > arrive and see what STR remains when connected to a SATA150 controller.
> > ATA overhead is ~10%. On top comes the serial protocol.
>
> Most PATA drives and mobos worth buying are ATA/100. I'm not
> accustomed to seeing overhead >20 or 25% for anything.
Read my lips: "On top comes the serial protocol".
And yes, SCSI protocol has about 25% overhead.
>
> > > > Look at ATA133. A modern IDE disk can deliver >50MB/s.
> >
> > > That is already pretty close to problematic.
> >
> > About 9MB/s data bandwidth ceiling remaining.
> >
> > > > Busses work best it they are not operated with their maximum speed.
> >
> > Nonsense. That's applies to networks, not point to point.
> >
> > >
> > > Is it really? that 50+MB/sec figure applies to serial reads along the
> > > outer platter rings.
> >
> > Yes and? You don't want them let go to waste, don't you?
>
> They won't really in many scenarios. Point is, though, they also are
> not the "norm" across the whole disk. Once you install the OS, for
> example, they are rarely utilized.
>
> > > With all the latency limitations, etc
> >
> > What latency limitations.
> > STR includes latency (head switches, cylinder switches).
> > The single track speeds are even higher.
>
> But data tends not to be written as nicely as this. Try transferring
> files you haven't handpicked for experiment and look at the average
> file transfer rate to another identical disk. That's what end-users
> really want to know when they look at external transfer rates.
> Playing with numbers and scenarios is misleading to real, practical
> concerns & questions.
Yet the resultant average transfer rates are still a function
of the sustained or single track transfer rates. Limiting them
also limits the average transfer rates although not linearly.
>
> > > they certainly never push files any where near that rate between drives.
> >
> > If big enough and contiguous, yes they do.
>
> Ahh- you see. File size and usage patterns again muddy the waters.
>
> > > I don't believe metadata take up most of the bandwidth.
> >
> > Huh?
>
> exactly.
>
> > > > > I always compare Ultra ATA 133 to putting Y rated tires on a VW
> > > > > bug (Y rated means they can go 186 MPH without coming apart).
> > > > > Just because the tires can go that fast doesn't mean the car can!
> > > >
> > > > Not fair. The tires have a safety margin. They will likely
> > > > not come apart at 200MPH either. However there is no way in
> > > > this universe to get more than 133MB/s over ATA133 and
> > > > the practical limit is more likely 80-100MB/s.
> > > >
> > > > Arno
> > >
> > > The point is the tires are overkill for the car. It has nothing to do
> > > with the accuracy of the speed rating of the tires or whether it truly
> > > is a maximal value.
> > >
> > > I agree, though, when you say "Busses work best it they are not
> > > operated with their maximum speed."
> >
> > Then you are as clueless as he is.
> > A bus operates at the same speed all the time. Data is transferred in bursts.
> > Not running an ATA133 bus at it's maximum speed is running it at ATA100.
>
> No you misunderstand & are making inaccurate assumptions.
I just read what is written there, and it was false.
> We are
> still talking about the relationship between the bus speed and the
> speed of the attached drives and at what point is the bus speed
> overkill and at what point is it inadequate for the drives attached.
Running a 60MB/s drive on an ATA66 bus is just fine. This will leave
no empy burst space on the bus, hence 100% (data) speed usage.
>
> I was referring to a situation where the drive/bus bandwidth rates are
> close and if you are counting on say ATA-66 to support 66MB/sec
> without taking into account the bandwidth lost to overhead, there is a
> problem.
Right, which is quite different to
"Busses work best it they are not operated with their maximum speed."
Facebook
Twitter
Instagram