Typical HDTach results for ATA133?

  • Thread starter Thread starter Ohaya
  • Start date Start date
Folkert said:
The design is 2 years old. The 800-BB almost 3 years.
It could be the 3rd incarnation of the drive though.
But like I said, no current 7k2 WD drive can do 60 MB/s, AFAICT.
Click to expand...

The JB is the one with the 8Mb cache. Perhaps that's affecting HDTach?
 
Mike Tomlinson said:
The JB is the one with the 8Mb cache. Perhaps that's affecting HDTach?
Click to expand...

No, the amount of cache does not affect HD Tach.
The JB was the 2nd incarnation of the WD800-BB, based on the WD1200
higher density platter configuration, IIRC. A little while after that the
WD800-BB got upgraded too.
 
Ohaya said:
Hi,

Ok, now I'm really confused. These are either ATA100 or ATA133 (the
Samsung) drives, right?
Click to expand...

With that 62 MB/s it better be ATA133/UDMA mode 6 (and it is).
A channel has to support 2 drives running simultaniously.
Shouldn't the read speed theoretically be approx.
100MB/s and 133MB/s, respectively?
Click to expand...

That's the burst speed.
If the tops is ~60MB/s, then isn't that like an ATA66 drive?
Click to expand...

Nope, ATA66 drives typically do less than 30MB/s.
Also, BTW, I don't remember if I posted it, but in testing with a clean
Win2K install and the Samsung drive, and using HDTach 2.70, I got burst
read speed of ~80MB/s.
Click to expand...

Like I said, it is best ignored as it measures the cache mechanism rather
than the burst speed. It is difficult to measure the burst speed (interface
speed) but very easy to read the same sectors which should 'in theory'
give you the bu(r)s(t) speed. (On SCSI drives of a few years back it was
not unthinkable that the burstspeed turned out lower than the Read speed
just because the cache didn't behave like expected). It's also possible that
you measure the limit of the PCI bus rather than that of the ATA bus.
 
Ohaya said:
[snip]


Rod,

Getting back to the original Subject of this thread then, what would you
expect the "typical" HDTach results to look like (burst read, read speed,
and utilization) for an "ATA133" drive vs. an "ATA100" drive?
Click to expand...

An ATA100 drive will usually have read speed limited to ~45MB/s or less
((busspeed/2)-10%)).
Could you (or anyone else) discern the difference between an ATA133 drive
and an ATA100 drive based on HDTach results?
Click to expand...

Burst speed.
If inconclusive, the read speed may give it away as an ATA133 drive when it
is over 45MB/s or so but it may still be an ATA100 drive because the drive
maker decided not to step up to ATA133.

The bus speed only matters when you access drives on the same channel simultaniously.
 
Folkert Rienstra said:
With that 62 MB/s it better be ATA133/UDMA mode 6 (and it is).
A channel has to support 2 drives running simultaniously.


That's the burst speed.


Nope, ATA66 drives typically do less than 30MB/s.


Like I said, it is best ignored as it measures the cache mechanism rather
than the burst speed. It is difficult to measure the burst speed (interface
speed) but very easy to read the same sectors which should 'in theory'
give you the bu(r)s(t) speed. (On SCSI drives of a few years back it was
not unthinkable that the burstspeed turned out lower than the Read speed
just because the cache didn't behave like expected). It's also possible that
you measure the limit of the PCI bus rather than that of the ATA bus.
Click to expand...

Hi All,

Thank you, this has been a very interesting discussion, for me at least. If
I'm understanding the discussion, I think that I have some empirical
evidence of it now.

If you recall, on the one Win2K install (the original one), I'm getting
burst speed of ~69MB/s, and read speed is showing ~60MB/s in HDTach 2.70.

On a clean Win2K install on the same system and using the same hard drive,
I'm getting burst speed of ~80MB/s, but even with this higher burst speed,
the read speed is coming in at ~63MB/s, i.e., approx. 3MB/s faster than the
original Win2K installation.

I think that this shows that even with the PC-to-drive interface is running
faster, the limiting factor is still the drive mechanics, as so many of you
have pointed out :)....


I'm still trying to figure out WHY I'm getting this difference in burst
speed between my original Win2K install and the clean Win2K install, but I'm
kind of suspecting something is "interfering" with the transfer rate.

I don't know for sure, but I'm kind of suspecting the Antivirus software
that is installed on the original Win2K (Mcafee). I did "disable" Mcafee
when I ran HDTach, but I'm wondering if even with it's disabled, Mcafee
might be leaving some kind of residual processing that slows the read speed
down.

Thanks again,
Jim
 
If you really want to track it down, you have to look for filter drivers.

Open device manager on both Win2Ks and view hidden devices. Filter drivers
show up under Non PnP. You can usually figure out the product by viewing
Driver Details.

You could also try the filter driver utility from bustrace.com.
 
Ohaya said:
Richard,

I agree that the CPU Utilization is high, but I also think that the
Read Burst Speed and Read Speed are low.

I did an experiment tonight, where I did a clean install of Win2K on
the system.

When I installed and ran HDTach on the clean Win2K installation, CPU
Utilization was ~14%, and Read Burst and Read Speed had gone up to
about 80MB/s.

On the original Win2K installation, I can't get that low CPU
Utilization and higher RBS and RS, no matter which IDE driver I used
(I've tried the default Windows driver, ALI 2.05, and ALI 1.04 (from
Asus)), all give approx. the same results.

This is really puzzling. It almost seems like something in the
original Win2K installation is somehow interfering with the HDTach
numbers, but I've run this with most processes shut down.
Click to expand...





After 10 trials with HD Tach 2.70, here are the average numbers I came up
with:

- Random Access Time: 14.3 msecs
- Read Burst Speed: 76.9 MB/sec
- Read speed - max 63.0MB/sec, min 36.9 MB/sec, average 53.3 MB/sec
- CPU Utilization: 25.5%

WindowsXP Pro,WD 800JB 8MB cache ATA100 7K2, A7N8X Deluxe Rev2, nVidia 3.13
drivers

With the exception of CPU utilization, the numbers did not change with new
chipset drivers. CPU utilization was in the 75-95% range before the driver
switch.
 
After 10 trials with HD Tach 2.70, here are the average numbers I came up
with:

- Random Access Time: 14.3 msecs
- Read Burst Speed: 76.9 MB/sec
- Read speed - max 63.0MB/sec, min 36.9 MB/sec, average 53.3 MB/sec
- CPU Utilization: 25.5%

WindowsXP Pro,WD 800JB 8MB cache ATA100 7K2, A7N8X Deluxe Rev2, nVidia 3.13
drivers

With the exception of CPU utilization, the numbers did not change with new
chipset drivers. CPU utilization was in the 75-95% range before the driver
switch.
Click to expand...


This looks very similar to what I'm getting with my clean Win2K
installation. The only significant difference was that I'm getting CPU
Utilization in the teens, from about 14% to 19%+.

Now to go figure why my original Win2K install can't do that :)...

Jim
 
Eric said:
If you really want to track it down, you have to look for filter drivers.

Open device manager on both Win2Ks and view hidden devices. Filter drivers
show up under Non PnP. You can usually figure out the product by viewing
Driver Details.

You could also try the filter driver utility from bustrace.com.
Click to expand...


Eric,

I compared the Non PnP drivers. Here're the ones on the original Win2K
install (the slower one) that are NOT on the clean Win2K install:

AppleTalk Protocol

aslm75 - Status: Started - driver is 'aslm75.sys', no other info in
Properties
- did search, and this appears to be Asus Probe - was stopped
when ran HDTach

FILEMON - Status: Unavailable - no info in Properties - I uninstalled
(see below)

NDIS Usermode I/O Protocol

NetBEUI Protocol

NWLink IPX/SPX/NetBIOS Compatible Transport Protocol

NWLink NetBIOS

NWLink SPX/SPXII Protocol

PfModNT - this one has a yellow exclamation mark

REGMON - Status: Unavailable - no info in Properites - I uninstalled
(see below)

Remote Access Auto Connection Driver

ScsiAccess - Status: Unavailable - no info in Properties

Unknown device - no info in Properites - I uninstalled (see below)

vsdatant - Status: Stopped - no info in Properties


I've tried to include notes in the above when I was able to find any
info. I don't know if the above provides much information :(...

I think that FILEMON and REGMON are artifacts from my running FILEMON
and REGMON from www.sysinternals.com.

I uninstalled both of them from Device Manager, and rebooted, and then
ran HDTach again. I also uninstalled the Unknown Device.

Still same results (somewhat slower bust read speed than clean Win2K,
69MB/s vs.
80MB/s).

Any thoughts on any of the others?

Jim
 
[snip]

The bus speed only matters when you access drives on the same channel simultaniously.
Click to expand...


I thought that couldn't be done with IDE/ATA.
Click to expand...

Yes and no. IDE does not allow concurrent transfers, but it does
support overlapped seeks. AFAIK, most IDE HDs don't support the
disconnected commands and command buffering that are needed to
make overlapped seeks work, but that's not the fault of the bus.
 
[snip]
The bus speed only matters when you access drives on the same channel simultaniously.
Click to expand...

I thought that couldn't be done with IDE/ATA.
Click to expand...

It can on large sequential accesses when the drive that is not accessed caches
the next data ahead internally while the other drive is accessed and v.v.
The data is then transferred from buffer at interface speed when the driver
requests that data.
 
Back
Top