Re: OT: performance problems.
>
> Linux piper 2.4.9 #1 Tue Sep 11 15:39:28 CEST 2001 i686 unknown
> 16:45:25 up 13 days, 1:17, 7 users, load average: 3.40, 3.56, 3.70
> 84 processes: 83 sleeping, 1 running, 0 zombie, 0 stopped
> CPU states: 0.8% user, 22.3% system, 1.0% nice, 75.9% idle
~~~~~~~~~~~~~
> Mem: 505844K total, 502788K used, 3056K free, 11456K buffers
> Swap: 996020K total, 31172K used, 964848K free, 438552K cached
>
> however, i am continuously having troubles. for instance, in a typical
> situation, i'd have windowmaker running with four terms, xmms playing
> some 192kbps MP3s, some ssh sessions into it, and an rsync, bzip/gzip,
> or make-kpkg process running. i am not usually interactively using X.
>
> in such a situation, xmms (or mpg123 without X, it doesn't matter)
> continuously skips on MP3s and it's *very* annoying. i even went as far
> as to renice xmms to -20 *and* rsync/bzip/gzip/make-kpkg to 20, but it
> doesn't really help.
>
First of all (stupid question): you aren't using esd or something alike?
Because although XMMS may get all the time it needs, esd may be starved...
Second: Even though one has -20 and the other 20 doesn't mean that the
last one won't get anymore time... For example, I use distributed-net
on some machines: Even though dnetc has nice 20 it ALWAYS has a minimum
of 5-10% CPU time.
I know WinNT has somekind of deadlock protection, where it increases the
priority of a starved process every tick until it got scheduled again.
(on another PC):
cat /dev/zero | bzip2 > /dev/null
PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
1721 root 20 -20 7768 7768 372 R < 90.4 6.1 0:35 bzip2
1702 daemon 19 19 460 460 384 R N 8.2 0.3 0:53 dnetc
1720 root -1 -20 372 372 308 S < 0.7 0.2 0:00 cat
CPU usage of dnetc NEVER goes under 8%...
Third: I have a similar computer (AMD 1.333 Ghz, 512MB 266Mhz DDR, 7200
IDE disk, kernel 2.4.x, MSI Turbo-Pro motherboard). I wanted to check
if the CD-writer was working OK (plextor clone) so I did
cat /dev/hdc | md5sum
on the original and copy. While I was doing that, load also got up to 3-4.
Looking at top, I saw that some kernel daemon (think kupdated) got *AlOT*
of CPU. The system also started responding slow (missing eth0 traffic,
...)
Maybe it's normal,
maybe it's a kernel bug (only seem to have it with AMD) / chipset bug?
Just some thoughts...
Dries
Reply to: