From MAILER-DAEMON Wed Sep 10 22:01:40 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KdbV6-0000IT-FV for mharc-bug-gnunet@gnu.org; Wed, 10 Sep 2008 22:01:40 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KdXU9-0004Ih-HI for bug-gnunet@gnu.org; Wed, 10 Sep 2008 17:44:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KdXU9-0004IV-2n for bug-gnunet@gnu.org; Wed, 10 Sep 2008 17:44:25 -0400 Received: from [199.232.76.173] (port=36615 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KdXU8-0004IS-TE for bug-gnunet@gnu.org; Wed, 10 Sep 2008 17:44:24 -0400 Received: from yx-out-1718.google.com ([74.125.44.153]:3445) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KdXU8-0000YY-Q2 for bug-gnunet@gnu.org; Wed, 10 Sep 2008 17:44:25 -0400 Received: by yx-out-1718.google.com with SMTP id 34so20954yxf.66 for ; Wed, 10 Sep 2008 14:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=c16NCgSO/i18f0BZV5L/sf2lCMtxDL4rwX8SdqedUEY=; b=CYUFpb29FJhQgXbEyHtNJThd9KCOJqBmY+6tLLYn+cH33MLmgFsxaU5yasAhR2/oxo pNj0OmShAoAgHKNpZjjQIu1UNonOZuxzBaPCm6pXXV979jMgMJLIfRpIWD4D8FV0zBR3 cqUeUBGHfILtk99Wk+55uxqmzxUEEe7t3dEHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=C4dKJssO/rWqHJDThGBg1Ybe9VSOVhUSz7iSmpBxHX3LsB5v8JXJDdsEtnwaacNQ/s Jwn9E+TaIM069Kz8hPl3YOeaegh8XD3r5U2I1ur1YMoFWUamlbwa4iFvE1lAQL+6LtWG d5hdww129OWYE2bYypVCHtq2Tr63hSBlFeLlk= Received: by 10.151.114.9 with SMTP id r9mr2804825ybm.108.1221083063383; Wed, 10 Sep 2008 14:44:23 -0700 (PDT) Received: by 10.150.205.10 with HTTP; Wed, 10 Sep 2008 14:44:23 -0700 (PDT) Message-ID: Date: Thu, 11 Sep 2008 00:44:23 +0300 From: "Juho Saarikko" To: bug-gnunet@gnu.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_34079_13572367.1221083063387" X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-Mailman-Approved-At: Wed, 10 Sep 2008 22:01:39 -0400 Subject: [bug-GNUnet] CPU limiter X-BeenThere: bug-gnunet@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Report bugs in GNUnet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2008 21:44:25 -0000 ------=_Part_34079_13572367.1221083063387 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline I wondered why GNUnet didn't get anything done, until I finally realized that I have Folding@home running in the background. Now, Folding is a batch job, and so consumes all CPU power available; this is not a problem, since I've set it to nice 20, so it doesn't interfere with the rest of the system, which is running on nice 0. Enter CPU limiter. Since CPU utilization is constantly at 100%, and thus over the default limit of 50%, GNUnet scales down its CPU use. Of course this doesn't accomplish anything, since the freed CPU cycles will simply be used by Folding, keeping CPU usage at 100% and causing GNUnet to back off even more. Of course the exact same will happen with any batch job, such as a long-running compilation, and at every limit under 100%. So I cranked it up to 101% and reniced gnunetd to level 10, after which it began working properly. Please drop the CPU limiter and use the OS scheduler priority/nice level instead. That not only gets rid of this bug, but also leads to less impact on latency. Or at least have a way - preferably compile-time - of completely disabling the CPU limiter. ------=_Part_34079_13572367.1221083063387 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I wondered why GNUnet didn't get anything done, until I finally realized that I have Folding@home running in the background. Now, Folding is a batch job, and so consumes all CPU power available; this is not a problem, since I've set it to nice 20, so it doesn't interfere with the rest of the system, which is running on nice 0.

Enter CPU limiter. Since CPU utilization is constantly at 100%, and thus over the default limit of 50%, GNUnet scales down its CPU use. Of course this doesn't accomplish anything, since the freed CPU cycles will simply be used by Folding, keeping CPU usage at 100% and causing GNUnet to back off even more. Of course the exact same will happen with any batch job, such as a long-running compilation, and at every limit under 100%. So I cranked it up to 101% and reniced gnunetd to level 10, after which it began working properly.

Please drop the CPU limiter and use the OS scheduler priority/nice level instead. That not only gets rid of this bug, but also leads to less impact on latency. Or at least have a way - preferably compile-time - of completely disabling the CPU limiter.
------=_Part_34079_13572367.1221083063387-- From MAILER-DAEMON Sat Sep 13 22:32:53 2008 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KehPw-000827-T1 for mharc-bug-gnunet@gnu.org; Sat, 13 Sep 2008 22:32:52 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KehPt-0007zF-SL for bug-gnunet@gnu.org; Sat, 13 Sep 2008 22:32:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KehPs-0007wP-BP for bug-gnunet@gnu.org; Sat, 13 Sep 2008 22:32:48 -0400 Received: from [199.232.76.173] (port=41706 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KehPs-0007wG-2E for bug-gnunet@gnu.org; Sat, 13 Sep 2008 22:32:48 -0400 Received: from nita.cs.du.edu ([130.253.191.9]:51791) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KehPr-0002S0-Pf for bug-gnunet@gnu.org; Sat, 13 Sep 2008 22:32:47 -0400 Received: from ip6-localhost (r1m2cl.cs.du.edu [130.253.191.151]) by nita.cs.du.edu (8.14.1/8.14.1) with ESMTP id m8E22qhH012960; Sat, 13 Sep 2008 20:02:53 -0600 (MDT) From: Christian Grothoff To: bug-gnunet@gnu.org, "Juho Saarikko" Subject: Re: [bug-GNUnet] CPU limiter Date: Sat, 13 Sep 2008 19:59:45 -0600 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200809131959.45262.christian@grothoff.org> X-ComputerScience-MailScanner-Information: Please contact tech support for more information X-MailScanner-ID: m8E22qhH012960 X-ComputerScience-MailScanner: Found to be clean X-ComputerScience-MailScanner-From: christian@grothoff.org X-detected-operating-system: by monty-python.gnu.org: Solaris 9 Cc: X-BeenThere: bug-gnunet@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Report bugs in GNUnet List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2008 02:32:50 -0000 Hmm. We used to have a simple way to set a nice value using gnunetd.conf -- I wonder how that got lost. Thanks for pointing out that this feature was no longer exposed. Anyway, I've added the code back in (most of it was still there) in SVN #7705. The CPU-limiter will stay however; there are some things that the OS can not do (like run different code instead of not scheduling a process). If you don't like it, simply set the limit very high (1000%). Christian On Wednesday 10 September 2008 03:44:23 pm Juho Saarikko wrote: > I wondered why GNUnet didn't get anything done, until I finally realized > that I have Folding@home running in the background. Now, Folding is a batch > job, and so consumes all CPU power available; this is not a problem, since > I've set it to nice 20, so it doesn't interfere with the rest of the > system, which is running on nice 0. > > Enter CPU limiter. Since CPU utilization is constantly at 100%, and thus > over the default limit of 50%, GNUnet scales down its CPU use. Of course > this doesn't accomplish anything, since the freed CPU cycles will simply be > used by Folding, keeping CPU usage at 100% and causing GNUnet to back off > even more. Of course the exact same will happen with any batch job, such as > a long-running compilation, and at every limit under 100%. So I cranked it > up to 101% and reniced gnunetd to level 10, after which it began working > properly. > > Please drop the CPU limiter and use the OS scheduler priority/nice level > instead. That not only gets rid of this bug, but also leads to less impact > on latency. Or at least have a way - preferably compile-time - of > completely disabling the CPU limiter.