HDD advice?

Ian Molton spyro at f2s.com
Fri Nov 15 02:11:19 PST 2002


On Fri, 15 Nov 2002 05:55:29 +0000 (UTC)
duncan at dwebb.ch ("Duncan Webb") wrote:

> > No. this isn't right unless your controller is B0rk3n.
> 
> The advice comes from Matrox, and it relates to capturing video and
> audio data from DV devices over FireWire, they spent quite a long time
> explain why it should be done this way. Up to you if want to try it
> ;-).

I listened for a while to some 'quite long' advice about how a 133MHz
memory system was 'interleaved' at 66MHz between a processor and video
chip so neither slowed the other down. needless to say, a load of
bollocks :-)

*windows* might be the cause of the problem matrox describe, but not the
hardware.

> IMHO, it is extremely unlikely that you would have received a faulty
> disk,

Thats optomistic at best - the first drive was definatley faulty - would
expire randomly with an audible 'click'.

the second one works, but is slow.

I was loathe to ring WDs support line, after they didnt get back to me
the first time, the line being in another *country* from me and rather
expensive to call...

HOWEVER, I spoke to a very helpful guy who said that as I had a previous
identical drive, which, despite the click, would pull 50MB/sec, and the
current one had some 20MB/sec performance dips (measured with zcat) that
'something wasnt right about that' and they would courier exchange the
drive at no cost to myself.

My faith in humanity is restored ;-)

> so it is possible that either your controller or cable is
> B0rk3n.

Unlikely. my original 20G ran /very/ fine, and the original defective WD
also ran fast.

> Do you have another PC to try the disk drive in

No. well, not one that is capable of running the drive to its max
speed...

>, because if
> you do then you could test the drive on that machine, it you don't
> then you could boot the machine under DOS and run a benchmark from
> there; this would elimininate your Linux configuration as possible
> problem.

DOS is a lousy platform to benchmark on.

> Running a benchmark on your system drive doesn't seem such a good idea
> because some of the background processes may be writing you log files,
> which would mess up your results.

That may cause one or two *minor* blips, but shouldnt cause sustained
performance drops. the guys at WD agree (I told them I tested under
linux).

I didnt remount RO or kill any tasks, but I have nothing running that
spews to the drive periodically, except syslog, which showed nothing
funny.

Anyhow, thanks all for the suggestions - especially the guy who
mentioned bonnie++ which I had forgotten about and contains the very
useful zcat.


-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe blfs-support' in the subject header of the message



More information about the blfs-support mailing list