Nope.
The 158 is the read channel bitrate. That's a measure that the drive
manufacturers seem to find interesting. (Its the spec on one of the
chips they put into the drive, just like the RAMDAC on your video
card). That 158 is Megabits per second.
>
> > 158 / 8 = 19.75MB/s or 19 megabytes per second.
> >
> > This is NOT the rated 33megs per second that the sheet claims for
> > UDMA operation. The rate for PIO/DMA is 16.6Mb/s. I get 7.8Mb/s
> > or roughly half of spec. Does this mean that if I use UDMA, I
> > can expect around double, or 15Mb/s? If so, that is far from
> > 33Mb/s, and still not quite even the calculated 19.75Mb/s that
> > the internal buffer supports.
>
> No. you'll probably see >11-12MB a second on the current generation of
> 5400rpm ide disks.
The 33Mb per second is "disk buffer -> computer" transfer rate. It has
nothing to do with sustained transfer speeds. It will do bursts with
this speed once it has the data in the internal buffer.
With your calculation of the internal transfer rate you have to
consider the following things:
- They might use 9 or 10 bits per byte (I don't think so).
- They use more than 512 bytes per sector. This is framing ("This is
sector number xyzxyz"), and CRC error information. You usually see
something like 622 bytes per sector.
- they achieve this bitrate near the outside of the platters. (the
beginning of the disk)
So given the the 158 Mbit per second, I'd say that 158/8/622*512 =
16.2Mbyte per second. That's not quite near the actual speed that I've
been able to get out of a disk.
Oh, one more thing, read the whitepaper about the bigfoot. It will
also tell you that "head switching times" are not neglegible. The
figure around the middle of the document uses 3 or 4 ms as the head
switching time.
> > What gives with these specs? What is even more confusing is that
> > at the bottom of the document it says "Quantum defines a megabyte
> > as 1000000 bytes". That adds a hell of a lot of confusion to
> > their datasheets, and accepted standards. I realize that Quantum
> > is not the only drive manufacturer doing this however - they all
> > do it.
>
> They do this primarily to inflate the size of their disks.
Right.
> > Question: How can one tell what the true speed will be for a
> > given drive from a given manufacturer? Is there a formula? My
> > formula is currently: rated-internal-buffer-rate/8 * 0.40
>
> There is no formula. Theoretical limits based on assumptions of rotational
> speed, head performance, cache perfromance and various signaling rates are
> always going to be radically higher than the actual performance of a
> drive. With a decent scsi controller and a bunch of drives performance can
> begin to approach the media speed, but not with an individual disk (short
> of something like a quantum rushmore ssd (which is not technically a
> disk)) and not with ide, given only two disk per channel and one operation
> at a time.
In theory, with the above disk, you should be able to do 16Mb per
second. (on the outer tracks) In theory, you can put two of these on
an UDMA bus. In theory, you could use RAID0 on them, and distribute
the load between the disks. In theory, you could then alternate
between the disks, transferring data form one while the other is doing
the read-ahead on the next "block".
In practise, you get about 5 - 10 Mb per second out of one disk, and
the next disk needs to be on a different controller to get any decent
performance out of the two.
My Quantum gets about 5.7Mb per second on the first 100Mb:
time dd if=/dev/hda of=/dev/null bs=1024k count=100
-> 17.95 seconds "elapsed time".
Fiddeling with hdparm doesn't make a difference that I could measure.
Roger.
-- Actor asks a collegue: "To what do you owe your success in acting?" Answer: "Honesty. Once you've learned how to fake that, you've got it made." -------- Custom Linux device drivers for sale! Call for a quote. ---------- Email: R.E.Wolff@BitWizard.nl || Tel: +31-15-2137555 || FAX: +31-15-2138217- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html