linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
>
>  
>

  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).