Date: Thu, 11 Mar 1999 17:31:11 +0100 (CET) From: Thomas Schuerger <schuerge@wurzelausix.CS.Uni-SB.DE> To: gjb@comkey.com.au (Greg Black) Cc: freebsd-questions@freebsd.org, freebsd-bugs@freebsd.org Subject: Re: Scheduling bug? Message-ID: <199903111631.RAA03067@wurzelausix.cs.uni-sb.de> In-Reply-To: <19990311120046.23069.qmail@alpha.comkey.com.au> from "Greg Black" at Mar 11, 99 10:00:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > When having two processes running, one with nice-level 0,
> > > the other one with nice-level 19 and both consuming as much
> > > CPU time as possible (e.g. an endless loop), FreeBSD will do
> > > a 2:1 time-slicing (that is, the first process will get 66%
> > > of the CPU-time and the other one 33%). For a test, just
> > > start two Perl processes doing a "while(1) {}", renice one
> > > of the processes to 19 and watch the "top" output.
>
> [...]
>
> > It's impossible given the test that you created to accurately
> > _measure_ this difference, as you're relying on an interpreted
> > (perl) loop - I'd be interested to see the same results with an
> > executable that was looping - so as to remove the layer of the
> > interpreter.
>
> The real point is that top is a useless tool when it comes to
> this kind of comparisons. You're just as likely seeing
> variations in the performance of top, as learning anything about
> the actual time slices.
>
> FreeBSD may suck in this area, but you'd have to do some proper
> testing to find out. This means writing some code that does
> useful work (never busy loops) and measuring the amount of work
> that gets done. It's harder than it sounds.
I'd say that this is proper testing. I am running the RC5 keycrack
client in the background (www.distributed.net), which can be
considered as being an endless loop with no disk/network i/o
(disk/network is accessed once within some hours).
The process is automatically running with nice-level 19.
Now, anything that's cpu-intensive in the foreground (e.g. compilation,
GIMP or whatever) will get only 66% of the cpu-time, because the
background process is not scheduled properly (this is not a matter
of what 'top' displays, it's what can really be measured when e.g.
applying effects in GIMP to an image). Even when doing disk
i/o in the foreground, like when rebuilding the 'locate' database,
this will be a lot slower. When killing the background process while
rebuilding the 'locate' database, the harddisk accesses are much more
frequent and it terminates a lot earlier.
When reading data from cdrom, this is also GREATLY affected by the background
process and makes reading speed about 1/4th as when the process is not
running! Copying a 4 MB file from cdrom to /tmp took 12.65 seconds when the
process was active and (another) 4 MB file took 2.83 seconds (both files
were NOT in the cache, just the directory structure of the CD was). This
was tested on an Ultra-SCSI CD-ROM (Pioneer 36x) and Asus 7890 U2W controller
with FreeBSD 4.0-Current.
Things like network transmission also suffer from cpu-intensive background
processes, which can be measured as well. I did transfers with and without that
process in the background, which came from a near-by FTP server. Download
rate using 'wget' was 270 KB/sec on average without the process and 170 KB/sec
when the process was running. I did each of the two tests 10 times...
I really do think this is rather serious and there should be some changes in
the kernel in the future. I would also give this thing a high priority, as it
affects system performance a lot.
Ciao,
Thomas.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903111631.RAA03067>