Hi, Yesterday, 20 hours, 9 minutes, 41 seconds ago, Christian Grothoff wrote: > What did you configure your MAXCPULOAD to be? Is it reall CPU consumption or > is your GDBM database thrashing the harddisk? How much bandwidth did you > give to your peer?
I set `MAXCPULOAD' to 50 (the default value) and a maximum bandwidth of 50 kB/s in both directions. It is actual CPU consumption, not I/O (looking at Gkrellm makes it very clear). I'm curious about how CPU consumption limitation is implemented. Could you give me pointers to the file(s) where this is done? > It's not about how many threads there are, it is about the algorithms that > are > used. GNUnet can burn a large number of cycles trying to find (possibly > approximate) solutions to an NP-complete problem that improves bandwidth > utilization. GAP itself is rather innocent here, it's the bandwidth > allocator and (depending on your crypto library and other things) sometimes > the public-key crypto. Fasttrack does not use that much (if any) crypto and > does not have the bandwidth scheduler. And that's where the CPU usage by > gnunetd goes into. Does that mean that disabling bandwidth limitation should yield less CPU consumption? My point about preemptive multithreading is that it is sometimes considered harmful compared to cooperative multithreading or event loops [1, 2]. Thanks, Ludovic. [1] http://www.gnu.org/software/pth/pth-manual.html#the_compromise_of_pth [2] http://www-sop.inria.fr/mimosa/rp/LOFT/doc/book/book-1.html#container1084 _______________________________________________ Help-gnunet mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnunet
