CPU limiter

[Juho Saarikko-2]

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.

_______________________________________________
Bug-GNUnet mailing list
Bug-GNUnet@...
http://lists.gnu.org/mailman/listinfo/bug-gnunet

[Christian Grothoff]

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.

_______________________________________________
Bug-GNUnet mailing list
Bug-GNUnet@...
http://lists.gnu.org/mailman/listinfo/bug-gnunet