"Interesting Multitasking Bug" update

aidas@ixsrs4.ix.netcom.com
Wed, 29 Jan 1997 21:28:14 -0600 (CST)


People that know what I'm refering to, skip two paragraphs down.

I recently wrote to the list refering to an annoying side of the Linux
scheduler. I run Timidity, which is a program that uses an on-disk patch
set (which it loads into memory) to play MIDI files through the DSP
device. It's extremely sensitive to losing its time slice, and it's very
obvious when it does -- the sound skips.

I noticed a while back that if I'm running Timidity and I use various
programs, it will skip. This always happens when a large amount of text is
scrolling onto the screen. For instance, if I log into an FTP site using
ncftp and then list a large directory, NCFTP apparently monopolizes the
scheduler. Keep in mind I'm running timidity with a -20 priority.

Anyway, to the new material. While I'm not so interested in fixing the
prolem with Timidity specifically, I am interested in fixing this problem
with whatever other processes I have.

At the suggestion of various people on this list, I added the following
code to Timidity's main() function:

struct sched_param scpm;
scpm.sched_priority = 98;
sched_setscheduler(0, SCHED_RR, &scpm);

If my setting sched_priority to 98 is a bad thing, someone needs to let me
know. :) If the value of 0 for the first argument is bad, be advised I've
also tried getpid() in there.

This didn't appear to fix the problem. It *may* have made it a little
better, but it's extremely hard to tell. The sound still skips. Putting
text up on the screen shouldn't eat loads of processor time, particularly
not time that isn't preempted.

The other process I've had this happen with is Tiny Fugue. Both are
compiled with the Curses library. That seems to be the contributing
factor.

I used to have this problem on my old 386 when playing MOD files (again,
noticable because it'll skip) during things like 'ps' output. It's a bit
annoying to have it happen on a P133. ;)

Regards.