On 8 Feb 2005 14:53:46 -0800, news@celticbear.com staggered into the
Black Sun and said:

Sorry about the delay--dangit, too many other things going on.

> Dances With Crows wrote:
>> On 8 Feb 2005 13:28:09 -0800, news@celticbear.com staggered into the
>> > This is a lot of information! I had no idea any of this was
>> > available, like this. (I really need to take some serious Linux
>> > courses or something.)
>> it's just a matter of having enough time to read all the man
>> pages/READMEs and so forth. This may not be possible for you,
>> though. You can always grab the latest paper edition of _Running
>> Linux_ if you're looking for course materials, though.
> Yeah, I know. Most of what I know has come from MAN and newsgroups.
> Thing is, I don't know that I didn't know something until I find out I
> didn't know it. So, I didn't know to look for it. =) Make sense?

Sure. There's a fairly good tutorial on Unix-like things at
http://www.icon.co.za/~psheer/rute-home.html , which may provide you
with a bunch of new things to get confused by :-) .

> Like the hdparm and uname and lsmod...I had no idea whose commands
> existed until I was asked what they output. How would I have known to
> find out about their existance just on my own? Which is why some
> intensive class, or good book, is really useful. Something I can go
> through and learn all the basics I should know.

Try the URL above first, go through as much of it as you want, and maybe
buy a paper copy at your local MegaBookStore? For more advanced stuff,
you can try lurking on various comp.os.linux.* newsfroups, reading the
threads that seem interesting to you and so forth.

> Oh, someone else simply said "And overdriving PCM on this box causes a
> lot of distortion." That's all, so I was wondering what that meant.

OK, I think this means "if the volume's too high, the sound gets
distorted." That's reasonably common, when the gain is high, you end up
with clipping and such. The time-honored cure for that is to buy more
expensive audio equipment, but that's probably not an option here.

> # hdparm -i /dev/hda
> /dev/hda:
> Model=Maxtor 6Y120P0, FwRev=YAR41VW0, SerialNo=Y40T38DE
> BuffType=DualPortCache, BuffSize=7936kB, MaxMultSect=16, MultSect=16
> UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma6
> AdvancedPM=yes: disabled (255) WriteCache=enabled
> * signifies the current active mode
>
> Hmm. OK, I can't quite decipher this. (*sigh* and I need to take an A+
> course as well.)

IMHO, the A+ stuff isn't worth it. A few years back, I bought a copy of
_Upgrading and Repairing PCs_ that included a CD-ROM with sample A+
exams on it. I read the book, took the sample exams without doing any
real studying, and scored very highly on every part of them except the
questions that dealt with Windows 3.1. YMMV on that, of course!

> I assume that DMA IS on since there's a min/rec values...but then,
> there's no asterik next to one of the mdma modes. Which doesn't
> matter since UDMA is being used, right?

Yep, *udma5 indicates you're using UDMA-5, which is pretty fast.

>> playing mp3s, right? If that's the case, you might want to set
>> unmaskirq to 1 and IO_support to 1. "hdparm -u1 -c1 -d1
>> /dev/hd[abcd]" as root should do the trick. Unmasking interrupts on
>> your IDE chains will actually make the disks perform a little more
>> slowly, but disk activity won't affect userspace programs as much.
> Fascinating! I read the man on this. I had no idea about these options.
> I look forward to improved general performance. =)

hdparm can do a lot of things, but not all of them are totally supported
on all hardware, and the "drive sleep" options are overridden by the
kernel's IDE code in most cases.

> Every time I discover yet another mysterious method of more detailed
> control Linux grants I get the increased feeling that there is a
> magical combination of settings and switches that is properly set will
> turn my PC into a Beowulf cluster.

Not quite, but there are a lot of things you can tweak. Something a few
people do is run X at a higher priority (like -5) to improve GUI
response. This should really not be necessary (and might even make
things slower) with a 2.6 kernel and the preempt thing enabled, but it's
yet another thing to try.

> It's just a matter of learning all the arcane secrets. fnord

Shh... they'll *hear* you! (Have you buried your $3000 in the backyard
yet?)

>> The ALSA modules may be having problems with this card, setting
>> registers incorrectly or doing something stupid. @#$%ing
> # uname -a
> Linux WEBDEV01 2.6.10-1.760_FC3 #1 Wed Feb 2 00:14:23 EST 2005 i686
> Is that right? i686 CPU? Is that what a Pentium-4 reads as?

i686 is gcc's definition for "PPro-compatible CPU". The Fedora stock
kernel is probably compiled for a PPro, because that kernel will run on
{PPro,PII,PIII,PIV,Athlon,AthlonXP,Duron} CPUs without recompiling. You
can recompile the kernel and tell it to optimize for a PIV--then it
probably won't run on anything but another PIV. Performance gains will
probably be minimal, but you may want to run a benchmark or 3 with your
new PIV-only kernel and compare to the 686-version.

>> If you're using ALSA, the appropriate output plugin for xmms is the
>> that references ALSA. aRts is KDE's sound server, and you should use
> Well, I SUPPOSE I'm using ALSA...at least that what this means, yes?
> # cat /proc/asound/oss/sndstat
> Sound Driver:3.8.1a-980706 (ALSA v1.0.6 emulation code)

Yep. If ALSA weren't loaded, /proc/asound/ wouldn't exist.

> So, I should just stick with ALSA and fiddle with that. Interesting,
> when ALSA is my selected output in XMMS, all tasks occur immediately.
> That is, pause, changing slider, volume, everything happens
> immediately. When I use aRts there's a couple second pause before
> anything takes effect. I assume, knowing now that KDE uses aRts, that
> it's because it's sharing processing with KDE...which is also why
> while XMMS is running with aRts selected none of the desktop sounds
> run, while with ALSA I can still hear KDE sounds at the same time.

This seems a little weird to me. I don't use aRts, mostly because I
think computers shouldn't make noise unless they're playing movies,
music, or games. aRts is supposed to allow multiple sound inputs (xmms
and KDE's desktop sounds) to coexist on the same sound output device,
and if that's not happening, there may be a bug (or funny configuration
problem) somewhere.

Hope this helps,

--
Matt G|There is no Darkness in Eternity/But only Light too dim for us to see
Brainbench MVP for Linux Admin / mail: TRAP + SPAN don't belong
http://www.brainbench.com / Hire me!
-----------------------------/ http://crow202.dyndns.org/~mhgraham/resume