Alternative to k3b? or why is everything soooooo slow?
Ben Scott
dragonhawk at gmail.com
Tue Nov 8 14:33:00 EST 2005
On 11/6/05, Bruce Labitt <bruce.labitt at verizon.net> wrote:
> Thanks for some insight on the problem. hdparm -i returns
> # hdparm -i /dev/hdc
For finding out what hdparm "features" are set, the output of
"hdparm /dev/hda" tends to be somewhat more useful, and certainly more
concise.
> It looks like it is udma4, doesn't it?
That's what that appears to say. I'm not entirely sure how well
that relates to the "-d" switch, though. IDE is screwy. For all I
know, it could be in UDMA4 mode but not actually using DMA.
> hdparm -c1 -d1 -u1 /dev/hdc means set IDE32 bit mode, set dma mode on,
> and set unmaskirq flag?
Yuppers. I find those three yield a great performance boost.
Furthermore, I've never had any serious trouble with any of them on
any hardware made in the past five years. The worst I've seen are
systems that, upon the first access, immediately emit a message to the
effect of "DMA didn't work, turning it back off". Never any data
corruption or other nastiness. YMMV, of course, but I feel these
three are pretty safe in this day and age.
The link Ted posted also suggested "-c3", which I haven't been
using. That might be worth trying.
Said link also pointed out something I tend to just assume: *ALWAYS*
back up your data. (I won't even say "...before trying anything."
You should have backups. Period. If you don't, sooner or later, you
will loose data. Guaranteed.)
> What does set unmaskirq flag do?
As Ted posted, it lets the system do other things while servicing
the IDE bus at the same time. It results in a huge boost in
interactive responsiveness, and should solve your clock lossage
problem, at least.
> Will the command string above change the dma mode?
I'm not really sure. My guess is that "-X" sets the
PIO/DMA/whatever mode, and "-d" tells the IDE driver to actually use
DMA features. But that's just a guess.
> It still thinks it is in udma4 mode, not PIO. Hmmm.
PIO is "bad", so using UDMA is a good thing. One can ass-ume that
the higher the number, the faster it is. :)
As I understand it: PIO (programmed I/O) means the CPU has to handle
feeding data to the IDE controller, in very small chunks. DMA (direct
memory access) means the CPU just says "Hey controller -- transfer
to/from this memory". That being said, when talking IDE, "UDMA" seems
to sometime refer to the controller/drive interface, not the
controller/RAM interface. I'm not sure how all that works.
> As for media, I bought a bunch of RiDATA DVD+R's. I suppose I'll have
> to pick up some other media to try, maybe some -R's...
Like I said, check with the drive manufacturer for recommended
media. It's not (just) a question of media quality -- it appears some
drives just like certain media manufacturing methods/materials better.
-- Ben "Backup often" Scott
More information about the gnhlug-discuss
mailing list