I think I'll try messing around with this - from what's been said the
performance improvements are quite good. I presume the Ultra-DMA howto and
man for hdparm is all I need (and copies of the thread emails).
> -----Original Message-----
> From: Tom Brinkman [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, October 06, 1999 10:42 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [newbie] Removing my windows hard drive
>
> > > A second query out of interest:
> > > In my current setup Windows is installed on a standard hard drive,
> > > while Linux uses a DMA33 capable drive. The bios has DMA/33 enabled
> > > however my understanding is that if the master device on an ide port
> > > is not DMA/33 capable then the slave cannot operate DMA/33. What I
> > > would like to know is - after I change my system around and remove
> > > Windows, will Linux take advantage of the DMA/33. During boot up I
> > > see that the kernel makes certain optimisations for the various hard
> > > drives so does the kernel do some sort of probe during boot to
> determine
> > > if DMA/33 is present, or is there some other initialisation script
> that
> > > contains that information?
> > >
> > > Actually it would seem this info has been answered in another thread
> (i
> > > think). I would still like to know if you can optimise a slave drive
> > > for DMA/33 while having the master at standard.
> >
> > I can't answer this one. Sorry.
> >
> > --
> > -Matt Stegman
> > <[EMAIL PROTECTED]>
> --
> I believe the 'another thread' is prob'ly Steve and my
> exchange about optimizing HDD's using 'hdparm'. I have Windows
> on ide0 master, and Linux on ide0 slave. I was able to optimize
> ide0 slave and enable DMA without doing the same for ide0 master.
> Both my WD's are UDMA capable, but I'd bet you'll have no problem
> with enabling DMA on one drive whether it's master or slave, or
> even putting them both as master on ide0 and ide1.
>
> To avoid any confusion, I believe DMA, UDMA, DMA33, and UDMA2
> are all one in the same, just different terms for the same direct
> memory access.
>
> .. Tom Brinkman [EMAIL PROTECTED] .
>
