From owner-freebsd-questions Thu Mar 11 8:33: 8 1999 Delivered-To: freebsd-questions@freebsd.org Received: from uni-sb.de (uni-sb.de [134.96.252.33]) by hub.freebsd.org (Postfix) with ESMTP id 92DA914BF7; Thu, 11 Mar 1999 08:33:03 -0800 (PST) (envelope-from schuerge@wurzelausix.CS.Uni-SB.DE) Received: from cs.uni-sb.de (cs.uni-sb.de [134.96.252.31]) by uni-sb.de (8.9.3/1999020800) with ESMTP id RAA08739; Thu, 11 Mar 1999 17:31:13 +0100 (CET) Received: from wurzelausix.cs.uni-sb.de (wurzelausix.cs.uni-sb.de [134.96.247.1]) by cs.uni-sb.de (8.9.3/1999020800) with ESMTP id RAA26154; Thu, 11 Mar 1999 17:31:12 +0100 (CET) Received: (from schuerge@localhost) by wurzelausix.cs.uni-sb.de (8.9.1/wjp/19980821) id RAA03067; Thu, 11 Mar 1999 17:31:12 +0100 (CET) From: Thomas Schuerger Message-Id: <199903111631.RAA03067@wurzelausix.cs.uni-sb.de> Subject: Re: Scheduling bug? To: gjb@comkey.com.au (Greg Black) Date: Thu, 11 Mar 1999 17:31:11 +0100 (CET) Cc: freebsd-questions@freebsd.org, freebsd-bugs@freebsd.org In-Reply-To: <19990311120046.23069.qmail@alpha.comkey.com.au> from "Greg Black" at Mar 11, 99 10:00:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > 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