Slow Write Speed on SATA WD2500JD's

[Guest]

Archived from groups: rec.video.desktop (More info?)

Our current editor has 4 x 250 gig Western Digitals, consisting of 2 x
SATA (JD series) and 2 PATA (JB series).

Both of the two SATA drives have appallingly slow sustained write speeds
(around 6 to 9 MB/sec) - even when the drives are empty. This is
causing intermittent capture. However read speeds are pretty much as
expected, > 50 MB/sec.

The two parallel ATA drives *both* exceed 50 MB/sec on both read and
write using Canopus test software.

Win2K O/S caching is disabled - but little difference either way.

This one's almost gotta be an overlooked config item. Anybody able to
save me a bit of digging time here?

Editor hardware list:

Intel D865PERL mobo, P4 3Gig, 1024 DDR, 800 FSB, AGP dual head driving
21" and 19" monitors, WD 250 gig 7200 PATA x 2, WD 250 Gig 7200 SATA x
2, NTFS file system all partitions, Pioneer DVR-A07, Win2K SP3, ReelDVD
2.5 DVD authoring, TMPGEnc (CQ mode) encoding, Canopus DVStorm2,
TM-H140PN JVC Hi Res 750 line PAL monitor (calibrated). Editor is on a
1000 Gbit/sec network (3 machines).

TIA and regards,

Hughy.

 

[john]

Archived from groups: rec.video.desktop (More info?)

"Harry Kiri" <completelyfalse@harrykiri.com> wrote:

>Our current editor has 4 x 250 gig Western Digitals, consisting of 2 x
>SATA (JD series) and 2 PATA (JB series).
>
>Both of the two SATA drives have appallingly slow sustained write speeds
>(around 6 to 9 MB/sec) - even when the drives are empty. This is
>causing intermittent capture. However read speeds are pretty much as
>expected, > 50 MB/sec.
>
It probably doesn't apply here, but our last "appalling slow" drive
issue was caused by the drive accidentally running PIO, that due to
the controller not being enabled in BIOS. XP detected and used the
drive anyway, but not in DMA mode. Can't imagine why the problem would
be asymmetrical, though. Writes must not be being cached, or needing
retries.

 

[Guest]

Archived from groups: rec.video.desktop (More info?)

"John" <usenet@nospam.org> wrote in message
news:gdgpn0tl5jhlotrit7o239r48mtdj15ovq@4ax.com...
> "Harry Kiri" <completelyfalse@harrykiri.com> wrote:
>
> >Our current editor has 4 x 250 gig Western Digitals, consisting of 2
x
> >SATA (JD series) and 2 PATA (JB series).
> >
> >Both of the two SATA drives have appallingly slow sustained write
speeds
> >(around 6 to 9 MB/sec) - even when the drives are empty. This is
> >causing intermittent capture. However read speeds are pretty much as
> >expected, > 50 MB/sec.
> >
> It probably doesn't apply here, but our last "appalling slow" drive
> issue was caused by the drive accidentally running PIO, that due to
> the controller not being enabled in BIOS. XP detected and used the
> drive anyway, but not in DMA mode. Can't imagine why the problem would
> be asymmetrical, though. Writes must not be being cached, or needing
> retries.

Even though I discounted the drives running in PIO mode (as you suggest,
contra-indicated because of the high read speeds), I checked the modes
anyway. Unfortunately, device manager flags all four drives are running
in ultra DMA mode. I've never come across a drive reading in UDMA mode
but mode jumping to PIO for writes, but maybe this is possible. I
wondered if it could be a resource conflict, but haven't seen anything
to give weight to this (so far).

I confess I haven't looked at the Western Digital website, would sure be
embarrassing if the solution is sitting there on a forum or something.
I better go take a look.

Thanks,
Hughy

 

[Guest]

Archived from groups: rec.video.desktop (More info?)

"John" <usenet@nospam.org> wrote in message
news:gdgpn0tl5jhlotrit7o239r48mtdj15ovq@4ax.com...

> It probably doesn't apply here, but our last "appalling slow" drive
> issue was caused by the drive accidentally running PIO, that due to
> the controller not being enabled in BIOS. XP detected and used the
> drive anyway, but not in DMA mode. Can't imagine why the problem would
> be asymmetrical, though. Writes must not be being cached, or needing
> retries.

Long, boring post follows, with unsatisfactory outcome.

In regard to caching:

Firstly, I'm assuming that the selectable write caches (enabled/disabled
by the H/D drivers), and accessed through Win2K device manager, refer to
enabling a main memory write cache, not the small 2/8 MB cache on board
the Western Digital drives. Perhaps that isn't so? Anyone know for
sure? Assuming the driver is requesting main memory for the cache,
anyone know the protocol for how much is requested/allocated?

When configuring machines using operating systems prior to Win2K, I've
always disabled main memory write caches. Back in the old days (1997 to
2000) ... Adobe strongly recommended this (along with dozens of other
vital config items) which taken together, solved many of the myriad of
hardware problems that plagued system builders back then. For slower
machines, write caches were definitely out.

On our latest editor, I let the default main memory write caches, for
all four drives, remain turned on. This on the assumption that the
overall system is now so fast (and the cache would be so much bigger)
that no matter what housekeeping the O/S decides it must do, the data
rate will not overwhelm the bus's/caches/drives.

When the two SATA drives started dropping frames, I checked the
sustained write transfer rate (Canopus software) which gave varying
figures of between 6 - 9 MBytes per second on four (or maybe five)
repeated tests. Read varied between 50 to 60 MBytes/sec. I then turned
off the SATA caching and retested, getting pretty much the same result
for write (can't remember the read figures).

So then - into the H/D BIOS settings (all on Auto). Everything seemed
Ok, H/D settings compared against the Intel website BIOS user manual for
the mobo. No obvious problem, and I exited the BIOS without saving a new
configuration. Checked the security of the SATA cables, nice firm fit
on mobo and drive, checked jumpers on the drives, default settings and
OK. Blew out the processor heatsink grime, put the covers back on,
swore, booted, reset SATA drive caching back to on.

Retested both SATA transfer rates. Result varied from 20 to 40 MBytes
sustained transfer rate (bit low, but OK, because the SATA drives now
have a heap of video files on them).

Why the sudden improvement? I wish I knew. When you don't make any
known system changes (other than copying a heap of files onto the
drives), this sort of outcome makes you think: "Where did I screw up?"

There's no doubt that both drives were initially slow - the attempt to
batch capture a 2 cam wedding resulted in every file being terminated
prematurely on dropped frames. If transfer slows down again, I'll look
more carefully for any rogue processes.

Regards,
Hughy

 

[john]

Archived from groups: rec.video.desktop (More info?)

Thanks for taking the time for the update. "Heap of video files"
suggests that the write test is now using a different density zone.
But the delta is too big for that. Read-after-write with small write
size would beat up on write speed. There's probably a white paper
somewhere....

"Harry Kiri" <completelyfalse@harrykiri.com> wrote:

>Long, boring post follows, with unsatisfactory outcome.
>
>In regard to caching:
>
>Firstly, I'm assuming that the selectable write caches (enabled/disabled
>by the H/D drivers), and accessed through Win2K device manager, refer to
>enabling a main memory write cache, not the small 2/8 MB cache on board
>the Western Digital drives. Perhaps that isn't so? Anyone know for
>sure? Assuming the driver is requesting main memory for the cache,
>anyone know the protocol for how much is requested/allocated?
>
>When configuring machines using operating systems prior to Win2K, I've
>always disabled main memory write caches. Back in the old days (1997 to
>2000) ... Adobe strongly recommended this (along with dozens of other
>vital config items) which taken together, solved many of the myriad of
>hardware problems that plagued system builders back then. For slower
>machines, write caches were definitely out.
>
>On our latest editor, I let the default main memory write caches, for
>all four drives, remain turned on. This on the assumption that the
>overall system is now so fast (and the cache would be so much bigger)
>that no matter what housekeeping the O/S decides it must do, the data
>rate will not overwhelm the bus's/caches/drives.
>
>When the two SATA drives started dropping frames, I checked the
>sustained write transfer rate (Canopus software) which gave varying
>figures of between 6 - 9 MBytes per second on four (or maybe five)
>repeated tests. Read varied between 50 to 60 MBytes/sec. I then turned
>off the SATA caching and retested, getting pretty much the same result
>for write (can't remember the read figures).
>
>So then - into the H/D BIOS settings (all on Auto). Everything seemed
>Ok, H/D settings compared against the Intel website BIOS user manual for
>the mobo. No obvious problem, and I exited the BIOS without saving a new
>configuration. Checked the security of the SATA cables, nice firm fit
>on mobo and drive, checked jumpers on the drives, default settings and
>OK. Blew out the processor heatsink grime, put the covers back on,
>swore, booted, reset SATA drive caching back to on.
>
>Retested both SATA transfer rates. Result varied from 20 to 40 MBytes
>sustained transfer rate (bit low, but OK, because the SATA drives now
>have a heap of video files on them).
>
>Why the sudden improvement? I wish I knew. When you don't make any
>known system changes (other than copying a heap of files onto the
>drives), this sort of outcome makes you think: "Where did I screw up?"
>
>There's no doubt that both drives were initially slow - the attempt to
>batch capture a 2 cam wedding resulted in every file being terminated
>prematurely on dropped frames. If transfer slows down again, I'll look
>more carefully for any rogue processes.
>
>Regards,
>Hughy
>
>
>
>

 

[Guest]

Archived from groups: rec.video.desktop (More info?)

Were the SATA drives new? I remember reading somewhere about when a new
drive is powered up, the first 10(?) cycles the drives doesn't run at full
speed. After that it runs at it's capability.

Do a google if you want to know the details.

Siebe


"John" <usenet@nospam.org> wrote in message
news:20orn0tk56mfl3jdvgehp3ofu4u9iqt2kl@4ax.com...
> Thanks for taking the time for the update. "Heap of video files"
> suggests that the write test is now using a different density zone.
> But the delta is too big for that. Read-after-write with small write
> size would beat up on write speed. There's probably a white paper
> somewhere....
>
> "Harry Kiri" <completelyfalse@harrykiri.com> wrote:
>
>>Long, boring post follows, with unsatisfactory outcome.
>>
>>In regard to caching:
>>
>>Firstly, I'm assuming that the selectable write caches (enabled/disabled
>>by the H/D drivers), and accessed through Win2K device manager, refer to
>>enabling a main memory write cache, not the small 2/8 MB cache on board
>>the Western Digital drives. Perhaps that isn't so? Anyone know for
>>sure? Assuming the driver is requesting main memory for the cache,
>>anyone know the protocol for how much is requested/allocated?
>>
>>When configuring machines using operating systems prior to Win2K, I've
>>always disabled main memory write caches. Back in the old days (1997 to
>>2000) ... Adobe strongly recommended this (along with dozens of other
>>vital config items) which taken together, solved many of the myriad of
>>hardware problems that plagued system builders back then. For slower
>>machines, write caches were definitely out.
>>
>>On our latest editor, I let the default main memory write caches, for
>>all four drives, remain turned on. This on the assumption that the
>>overall system is now so fast (and the cache would be so much bigger)
>>that no matter what housekeeping the O/S decides it must do, the data
>>rate will not overwhelm the bus's/caches/drives.
>>
>>When the two SATA drives started dropping frames, I checked the
>>sustained write transfer rate (Canopus software) which gave varying
>>figures of between 6 - 9 MBytes per second on four (or maybe five)
>>repeated tests. Read varied between 50 to 60 MBytes/sec. I then turned
>>off the SATA caching and retested, getting pretty much the same result
>>for write (can't remember the read figures).
>>
>>So then - into the H/D BIOS settings (all on Auto). Everything seemed
>>Ok, H/D settings compared against the Intel website BIOS user manual for
>>the mobo. No obvious problem, and I exited the BIOS without saving a new
>>configuration. Checked the security of the SATA cables, nice firm fit
>>on mobo and drive, checked jumpers on the drives, default settings and
>>OK. Blew out the processor heatsink grime, put the covers back on,
>>swore, booted, reset SATA drive caching back to on.
>>
>>Retested both SATA transfer rates. Result varied from 20 to 40 MBytes
>>sustained transfer rate (bit low, but OK, because the SATA drives now
>>have a heap of video files on them).
>>
>>Why the sudden improvement? I wish I knew. When you don't make any
>>known system changes (other than copying a heap of files onto the
>>drives), this sort of outcome makes you think: "Where did I screw up?"
>>
>>There's no doubt that both drives were initially slow - the attempt to
>>batch capture a 2 cam wedding resulted in every file being terminated
>>prematurely on dropped frames. If transfer slows down again, I'll look
>>more carefully for any rogue processes.
>>
>>Regards,
>>Hughy
>>
>>
>>
>>
>

 

[Guest]

Archived from groups: rec.video.desktop (More info?)

"Fam. Dijkstra" <dijkstraremovethis@tpg.com.au> wrote in message
news:417e4386@dnews.tpgi.com.au...

> Were the SATA drives new? I remember reading somewhere about when a
new
> drive is powered up, the first 10(?) cycles the drives doesn't run at
full
> speed. After that it runs at it's capability.
>
> Do a google if you want to know the details.

No, both drives have had at least several hundred cycles.

Thanks, and regards,
Hughy.

 

[AnthonyR]

Archived from groups: rec.video.desktop (More info?)

That's what I was about to suggest, new drives check for bad sectors and
stuff the first 10 or so bootups, and then go into normal mode.
Is it possible that the caching was reset on the drives firmware somehow?
Just trying to figure out why the sudden improvement.

AnthonyR


"Fam. Dijkstra" <dijkstraremovethis@tpg.com.au> wrote in message
news:417e4386@dnews.tpgi.com.au...
> Were the SATA drives new? I remember reading somewhere about when a new
> drive is powered up, the first 10(?) cycles the drives doesn't run at full
> speed. After that it runs at it's capability.
>
> Do a google if you want to know the details.
>
> Siebe
>
>
> "John" <usenet@nospam.org> wrote in message
> news:20orn0tk56mfl3jdvgehp3ofu4u9iqt2kl@4ax.com...
>> Thanks for taking the time for the update. "Heap of video files"
>> suggests that the write test is now using a different density zone.
>> But the delta is too big for that. Read-after-write with small write
>> size would beat up on write speed. There's probably a white paper
>> somewhere....
>>
>> "Harry Kiri" <completelyfalse@harrykiri.com> wrote:
>>
>>>Long, boring post follows, with unsatisfactory outcome.
>>>
>>>In regard to caching:
>>>
>>>Firstly, I'm assuming that the selectable write caches (enabled/disabled
>>>by the H/D drivers), and accessed through Win2K device manager, refer to
>>>enabling a main memory write cache, not the small 2/8 MB cache on board
>>>the Western Digital drives. Perhaps that isn't so? Anyone know for
>>>sure? Assuming the driver is requesting main memory for the cache,
>>>anyone know the protocol for how much is requested/allocated?
>>>
>>>When configuring machines using operating systems prior to Win2K, I've
>>>always disabled main memory write caches. Back in the old days (1997 to
>>>2000) ... Adobe strongly recommended this (along with dozens of other
>>>vital config items) which taken together, solved many of the myriad of
>>>hardware problems that plagued system builders back then. For slower
>>>machines, write caches were definitely out.
>>>
>>>On our latest editor, I let the default main memory write caches, for
>>>all four drives, remain turned on. This on the assumption that the
>>>overall system is now so fast (and the cache would be so much bigger)
>>>that no matter what housekeeping the O/S decides it must do, the data
>>>rate will not overwhelm the bus's/caches/drives.
>>>
>>>When the two SATA drives started dropping frames, I checked the
>>>sustained write transfer rate (Canopus software) which gave varying
>>>figures of between 6 - 9 MBytes per second on four (or maybe five)
>>>repeated tests. Read varied between 50 to 60 MBytes/sec. I then turned
>>>off the SATA caching and retested, getting pretty much the same result
>>>for write (can't remember the read figures).
>>>
>>>So then - into the H/D BIOS settings (all on Auto). Everything seemed
>>>Ok, H/D settings compared against the Intel website BIOS user manual for
>>>the mobo. No obvious problem, and I exited the BIOS without saving a new
>>>configuration. Checked the security of the SATA cables, nice firm fit
>>>on mobo and drive, checked jumpers on the drives, default settings and
>>>OK. Blew out the processor heatsink grime, put the covers back on,
>>>swore, booted, reset SATA drive caching back to on.
>>>
>>>Retested both SATA transfer rates. Result varied from 20 to 40 MBytes
>>>sustained transfer rate (bit low, but OK, because the SATA drives now
>>>have a heap of video files on them).
>>>
>>>Why the sudden improvement? I wish I knew. When you don't make any
>>>known system changes (other than copying a heap of files onto the
>>>drives), this sort of outcome makes you think: "Where did I screw up?"
>>>
>>>There's no doubt that both drives were initially slow - the attempt to
>>>batch capture a 2 cam wedding resulted in every file being terminated
>>>prematurely on dropped frames. If transfer slows down again, I'll look
>>>more carefully for any rogue processes.
>>>
>>>Regards,
>>>Hughy
>>>
>>>
>>>
>>>
>>
>
>

 

[Guest]

Archived from groups: rec.video.desktop (More info?)

"AnthonyR" <toomuchspam@tolisthere.com> wrote in message
news:a0Dfd.177396$4h7.33934129@twister.nyc.rr.com...

> That's what I was about to suggest, new drives check for bad sectors
and
> stuff the first 10 or so bootups, and then go into normal mode.
> Is it possible that the caching was reset on the drives firmware
somehow?
> Just trying to figure out why the sudden improvement.

Yes, not having a definitive answer annoyed me too, so I revisited the
write speed issue again today and it is definitely *not*
fixed as I had thought.

Firstly, due to me misidentifying which cache I had turned off, I
wrongly identified *both* SATA drives as being slow write speed.

In fact, only the SATA drive on interface 1 was performing badly, ie.
"SATA-1". The situation is now as follows:

When write caches for both SATA drives are turned on, SATA-0 hits 50
MBytes/sec read and 56 MBytes/sec for write (with virtually no change
over dozens of tests), whilst SATA-1 varies substantially between (10 to
47) read and (9 to 32) write. I (quick) reformatted SATA-1 prior to the
tests - writes would theoretically have been performed on the outermost
(and fastest) tracks.

The performance of SATA-0 is entirely consistent with the two drives on
the parallel interfaces (IDE-0 and IDE-1, both masters on their
respective interfaces). So - each of these 3 drives consistently give
very close to 50 MBytes/sec read and 56 MBytes/sec write consistently.
Not so for SATA-1.

Turning the write caching off brings the write performance of both SATA
drives down below 10 MBytes/sec, however interestingly, SATA-1 is still
(on average), a fair bit slower than SATA-0.

The next test ... I put the drive that was on SATA-0 onto the SATA-1
interface. For gods sake it gave a totally consistent 50MBytes read and
57 MBytes write - over and over again!!! So there's nothing wrong with
the interface itself. Putting the (now highly suspect) SATA-1 drive
onto the SATA-0 interface gave a marginally improved performance, but
still nowhere near the consistent performance of the drive normally on
this interface.

I now think I have a WD2500JD (250 gig SATA) drive that has a problem.
All I have to do now is get some WD diagnostic testing software to agree
with me (the drive's still under guarantee) ... I'm not sure how easy it
will be to prove the drive has a fault, given that in all other respects
the drive is performing normally.

I'll try replacing the serial cable between controller and drive, if
that doesn't work then I'll low level format, but I've never seen any
improvement gained from low level formats before - especially from
fairly new drives.

Regards,
Hughy

 

[AnthonyR]

Archived from groups: rec.video.desktop (More info?)

"Harry Kiri" <completelyfalse@harrykiri.com> wrote in message
news:417fc2cc$0$8006$5a62ac22@per-qv1-newsreader-01.iinet.net.au...
> I now think I have a WD2500JD (250 gig SATA) drive that has a problem.
> All I have to do now is get some WD diagnostic testing software to agree
> with me (the drive's still under guarantee) ... I'm not sure how easy it
> will be to prove the drive has a fault, given that in all other respects
> the drive is performing normally.
>
> I'll try replacing the serial cable between controller and drive, if
> that doesn't work then I'll low level format, but I've never seen any
> improvement gained from low level formats before - especially from
> fairly new drives.
>
> Regards,
> Hughy
>
>
>
Hughy,
I understand about you wanting both drives to have similar performance. If
the cable isn't at fault run the entire gamut of WD utilities and see if it
passes all the tests. If it does, it might be difficult for you to convince
tech support to issue you an RMA number for the drive, they usually want an
error code to be positive it's not your system causing the low performance.
It can be frustrating. Good Luck with whatever happens!

AnthonyR.

 

[john]

Archived from groups: rec.video.desktop (More info?)

"Harry Kiri" <completelyfalse@harrykiri.com> wrote:

>Yes, not having a definitive answer annoyed me too, so I revisited the
>write speed issue again today and it is definitely *not*
>fixed as I had thought. (...snip...)

Thanks very much for updating the group, and good luck on dealing with
the warranty replacement.
>

 

[Guest]

Archived from groups: rec.video.desktop (More info?)

On Thu, 28 Oct 2004 01:47:33 +1000, "Harry Kiri"
<completelyfalse@harrykiri.com> wrote:

>I'll try replacing the serial cable between controller and drive, if
>that doesn't work then I'll low level format, but I've never seen any
>improvement gained from low level formats before - especially from
>fairly new drives.

Given that the parallel interface of the drive gives good performance,
and you swapped the drives around on the SATA-controller, I would
suspect the SATA interface of the drive itself. Does the cable seat
properly on that particular drive?

cheers

-martin-

--
Can the terror of spam be included in the war on terror?

 

[Guest]

Archived from groups: rec.video.desktop (More info?)

Martin Heffels <tguei221@handbag.com> wrote in
newsa50o05cal9mc6jt15l0iujap3rtpjem8v@4ax.com:

> On Thu, 28 Oct 2004 01:47:33 +1000, "Harry Kiri"
> <completelyfalse@harrykiri.com> wrote:
>
>>I'll try replacing the serial cable between controller and drive,
>>if that doesn't work then I'll low level format, but I've never
>>seen any improvement gained from low level formats before -
>>especially from fairly new drives.
>
> Given that the parallel interface of the drive gives good
> performance, and you swapped the drives around on the
> SATA-controller, I would suspect the SATA interface of the drive
> itself. Does the cable seat properly on that particular drive?
>
> cheers
>
> -martin-
>

And I think it's time for a shot in the dark.

Has the offending drive been somehow set to the low-noise mode
(acoustical noise, I mean)?

I don't think it could make that much difference in performance, but it
seems appropriate to grasp as straws right now :-(

Gino

--
Gene E. Bloch (Gino) phone 650.966.8481
Call me letters find me at domain blochg whose dot is com

 

[Guest]

Archived from groups: rec.video.desktop (More info?)

"Martin Heffels" <tguei221@handbag.com> wrote in message
newsa50o05cal9mc6jt15l0iujap3rtpjem8v@4ax.com...

> Given that the parallel interface of the drive gives good performance,
> and you swapped the drives around on the SATA-controller, I would
> suspect the SATA interface of the drive itself. Does the cable seat
> properly on that particular drive?

The cable seats positively.

I swapped cables from each SATA drive to the other, with each drive
remaining on it's original SATA interface. There was no change in
either drives behaviour. This test did not disclose a faulty cable.

I then swapped each drive (together with its serial cable) to the
companion interface (0 to 1, and 1 to 0).

The slow and erratic drive behaviour follows the suspect drive to the
new interface. And the drive which has given a consistent read/write
speed, when swapped, still gives a consistent high performance on the
interface which was previously connected to the suspect drive. This
seems to prove that each interface is fine.

Both SATA interfaces will give a sustained read/write of 50/56
MBytes/second (with a remarkable consistency of only a MByte or two
difference in repeated tests), for the "good" drive. When the suspect
drive is connected, either interface gives wildly varying figures.

I downloaded Western Digitals "Data Lifeguard" diagnostics. To qualify
for warranty, the drive must fail the diagnostics. The "Smart" Tests,
which examine 15 drive parameters, don't detect any problem with either
drive. In fact, the 15 parameters of both SATA drives are almost
identical and within Western Digitals threshold. This makes a low level
format pretty much pointless.

The Canopus read/write testing software obviously isn't intended to be
as accurate as HDTach etc, however I can't see the Canopus software
being selectively erroneous. Besides which, that particular drive (and
only that one) drops frames on capture - I haven't had that problem on
any of our editors since 1998!

I'm open to other theories. Everything seems to point to a faulty
drive, yet the Western Digital diagnostics don't agree. All drives have
the write cache enabled, performance is dreadful without this (any
drive).

Any suggestions?

Regards,
Hughy

Equipment list:

Intel D865PERL mobo, P4 3GHz, 1024 DDR, 800 FSB, AGP dual head driving
21" Mitsubishi Diamontron and 19" Philips monitors, WD 250 gig 7200 PATA
x 2, WD 250 Gig 7200 SATA x 2, NTFS file system all partitions, Pioneer
DVR-A07, Win2K SP3, ReelDVD 2.5 authoring, TMPGEnc (CQ mode) encoding,
Canopus DVStorm2, TM-H140PN JVC Hi Res 750 line PAL monitor (colour bar
calibrated). Editor is on a 1000 Gbit/sec network (3 machines on
network).

 

[Guest]

Archived from groups: rec.video.desktop (More info?)

"Gene E. Bloch" <hamburger@NOT_SPAM.invalid> wrote in message
news:Xns958F9C0491B7Astrolabe@216.148.227.77...

> And I think it's time for a shot in the dark.
>
> Has the offending drive been somehow set to the low-noise mode
> (acoustical noise, I mean)?

I haven't seen any reference to a low noise mode in the specs.

http://www.westerndigital.com/en/products/current/drives.asp?Model=WD2500JD

I noticed a reference to mode 1 and mode 3, under heading accoustical.
As I couldn't find any reference to a low noise mode, I assume that is a
reference to RAID operation.

Regards,
Hughy