On Saturday 19 February 2005 06:51, Ludovic Court�s wrote: > Hi Christian, > > 6 days, 17 hours, 23 minutes, 7 seconds ago, > > Christian Grothoff wrote: > > I wonder if anyone else is having a problem with high CPU utilization by > > the _clients_ (not gnunetd)? > > Why not gnunetd? :-)
Because it would be a different issue ;-). > Last time I tried (several months ago), gnunetd was actually eating so > much CPU (even while I wasn't downloading anything) that I just > couldn't let it run in the background and listen to an mp3 at the same > time on my K6-2 350MHz (admittedly not a cutting-edge machine). Note > that this is on Debian unstable, with the GDBM back-end. 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? > Since then, I sometimes used aMule, a Python GTK-based implementation of > the Fasttrack protocol, and I was impressed by its relatively low CPU > consumption. Of course, Fasttrack may slightly differ from GAP. But > still, aMule didn't eat up all the CPU, even when content was being > dowloaded from and uploaded to my node at the same time. > > Gnunetd seems to be heavily multithreaded which may be one possible > cause of its CPU intensiveness. 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. Christian _______________________________________________ Help-gnunet mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnunet
