From: Tyler <pml@dtbb.net>
To: Saswat Praharaj <saswat@gmail.com>
Cc: Stefan Smietanowski <stesmi@stesmi.com>, linux-ide@vger.kernel.org
Subject: Re: read vs write
Date: Mon, 25 Jul 2005 05:34:05 -0700 [thread overview]
Message-ID: <42E4DC3D.1050900@dtbb.net> (raw)
In-Reply-To: <d15adc960507250440510efd58@mail.gmail.com>
My only suggestion would be to do some research using google.
a) 100MB/sec is an interface specification, anotherwords, the bus it
sits on, can do 100MB/sec. Take into account the fact that you may have
more than one hard drive on the same bus, and you soon figure out why
maxtor felt 133MB/sec may be useful, now that there are drives that can
do over 50MB/sec, multiply that by 2, and you are at or above the
100MB/sec bus rating. The PCI bus itself (the bus the IDE interface
attaches to and transfers across to the CPU), in 32bit, 33mhz form only
has a theoretical limit of 133MB/sec itself.
b) I'm guessing your processor is holding you back, or the chipset, or
the chipset drivers, or any combination therein. My first test would be
to put the drive in a faster system. Yes, I know your read speed was
higher, but reads *tend* to be higher to begin with. Thinking about
this again, and after reading the page i posted below, I would say you
are already hitting the drives limits, even without hitting a
motherboard/cpu limit, other than possibly the burst speed, which may be
slightly higher on an ata100 controller.
c) Here is possibly a better example than the highway: You buy a new
car off the lot these days, and it comes with tires, that are *capable*
of 150mph continuosly... does that mean automatically mean your car is
capable of running that fast? no. If you put 4 inch exhaust on your
vehicle, does that mean your engine will be able to flow at a rate
and/or pressure that can take full advantage of the 4 inch exhaust
systems capacity? no. Your speedometer goes to 160mph, does that mean
your car goes that fast? no.
and as a side note, 25MB/sec on a 400mhz machine, is an excellent speed,
as is 58mb/sec read speed. I would stop complaining or looking for
something to blame, and realize the hardware is at its limits. I
actually doubt that your barracuda drive is doing 58mb/sec, other than
possibly burst transfers.
try googling a little bit, and find reviews and information such as this
page:
http://www.xbitlabs.com/articles/storage/display/seagate-barracuda-ata4.html
Regards,
Tyler.
Saswat Praharaj wrote:
>yups I meant MBps ..thanks for correcting me .
>
>However, I dont agree with your ford/road example.
>
>I just checked the product specification of STA340016A (seagate) .
>
>Here is what they claim :
>
>[ This manual describes the functional, mechanical and interface specifi-
>cations for the ST380021A, ST360021A, ST340016A and ST320011A.
>These drives provide the following key features:
>· 7,200-RPM spindle speed and 2-Mbyte buffer combine for superior
> desktop performance
>· High instantaneous (burst) data-transfer rates (up to 100 Mbytes per
> second) using Ultra DMA mode 5 ]
>
>I have found average seek time is little faster (around 1ms) for read
>than write.
>Still that doesn't justify the write speed of 15-20 MBps and 55-60
>MBps for read.
>
>Can anyone help me understading how/why write is different than read.
>
>Thanks and Regards,
>Saswat
>
>On 7/25/05, Stefan Smietanowski <stesmi@stesmi.com> wrote:
>
>
>>-----BEGIN PGP SIGNED MESSAGE-----
>>Hash: SHA1
>>
>>Hi Saswat.
>>
>>
>>
>>>Moreover, I am wondering if I could achieve the 100Mbps read speed as
>>>claimed by different vendors.For me , It should ideally be 100 Mbps as
>>>I am using a 80 conductor cable and UDMA 5.Why then I am getting 58
>>>Mbps max . .
>>>
>>>
>>If you mean Mbps then you are already above it. 100Mbps = 12.5MB/s
>>give or take and both speeds are above that.
>>I guess you probably mean 100MB/s though and that is only what
>>the cable can take.
>>
>>If you take a T-ford onto the highway - can you go 130Km/h in it?
>>
>>No, the road is rated at 130Km/s but the car can't go that fast.
>>
>>Same here, the standard says you can transfer 100MB/s over the cable
>>but the disk isn't fast enough to be able to transfer that fast.
>>
>>// Stefan
>>-----BEGIN PGP SIGNATURE-----
>>Version: GnuPG v1.4.1 (MingW32)
>>
>>iD8DBQFC5L/BBrn2kJu9P78RAkXKAJ4vc/xQ0Z8mA1ddo79+wC6NCFe5VACgl+j+
>>ceP+as8dx0uZs2W6xaYiMVc=
>>=Of1/
>>-----END PGP SIGNATURE-----
>>
>>
>>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-ide" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
next prev parent reply other threads:[~2005-07-25 12:34 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-25 10:14 read vs write Saswat Praharaj
2005-07-25 10:32 ` Stefan Smietanowski
2005-07-25 11:40 ` Saswat Praharaj
2005-07-25 12:34 ` Tyler [this message]
2005-07-25 12:36 ` Stefan Smietanowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42E4DC3D.1050900@dtbb.net \
--to=pml@dtbb.net \
--cc=linux-ide@vger.kernel.org \
--cc=saswat@gmail.com \
--cc=stesmi@stesmi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).