Loren M. Lang wrote:
Certain tasks that have been doing on FreeBSD like installing ports seem
to interrupt my music playing. Particually when portupgrade is
extracting/checksumming and when it is updating the package database.
Now to try and solve this I tried to set xmms to use realtime priority
and made it setuid root. According to top it's running at priority 20
nice -76 so it seems to be running realtime, but portupgrade can still
interrupt the audio occasionally. I've tried nicing portupgrade before,
but I usually forget, though I'm not even sure if nicing it fixed the
problem. I've had this problem with FreeBSD 4.9 to 5.3 on two
completely different machines. Also I've had to stop distibuted.net
running before because I couldn't play movies with mplayer smoothly.
This was on a P4 3.0 GHz, 1G DDR 400 MHz ram. dnet always runs with a
nice value of 20 which puts it at about priority 131. Why are these
programs able to interrupt my multimedia programs so much. The
multimedia programs don't need to use much CPU time with systems as fast
as these, but they just need to make sure they get X work done in Y
amount of time. If their scheduled apropriately there should be no
conflicts, I've never really had this issues with linux, AFAIK. Is
there any better way to fix this?
I recently read an interview which I think is related with you
problem, this is a excerpt:
Quote:
Getting things out from under Giant has improved performance and
interactivity. There still remains however the problem of I/O
starvation (eg, the system slows to a crawl while extracting
large archives). What can be done about that, and are there
plans to do something about it?
A large part of the problem is that the vnode system grabs Giant
and while that happens nothing much else happens. In essence the
entire filesystem arena is single-threaded.
The phk_bufwork stuff cuts the bottom bit of this: Today when you
get down to the filesystem and it decides to read sector number foo
from the disk it asks the vnode system to do so, with phk_bufwork
it will send the request to GEOM instead which is a bit faster.
But getting the vnode layer more multithreaded is a nasty piece
of work which we can just keep chipping away at until we get to
the end.
read the whole interview:
http://forums.bsdnexus.com/viewtopic.php?p=2236
Regards
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
