Get some real hardware you whining puppy, not some $40 discard at 1st Saturday :-)
You should also be able to find this yourself in the code. grep for pthread_mutex_lock() and you'll see a #define to something called _accessMutex() - grep for that an the code in all it's glory is in util.c (he he he) Now that we're past that... ntop is multi-threaded. The fork() is the least of it - used only for 'read-only' web pages. For normal running, there are six or seven threads at any time that are running - web server, one per interface, one decoder, one or more address resolution, main thread, idle purge, usually some sort of thread manager, etc. ... The biggest difference between 2.2 and 2.3 is that we've moved ntop from a multi-threaded, unprotected application to a multi-threaded protected one. So the mutexes are in place to protect data across the threads. It's amazing how SMP hardware changes your view of the world - it really is possible for the purge to be running and purging hosts at the same time the decoder is trying to record packet information about them! Intelectually, you always new it COULD happen, but in years and years of running ntop, I don't think Luca ever saw the problems. The issue is that thread programming is subtle and hard. We actually saw that case where code of the form: if (ptr == NULL) ptr=malloc(); <...2 or 3 irrelevant lines, no function calls, just open code...> ptr->x++; was bombing... And, it's almost impossible to diagnose after the fact (especially when the debugger, gdb, changes the thread model and so you don't see the problems). To combat all that, we added information to the POSIX pthread_mutex_t to track which thread did the lock/release and where in ntop's code this comes from. This is very useful data in diagnosing and fixing deadlocks - which we've introduced more than once during the 2.3 development cycle. I *think* things are stable now, but you never know - and so I've got zip interest in removing that data. For example, if you run with -K and the decoder locks up, the info.html page will show the mutex information (as will the PR form, IIRC) - that's crucial for diagnosis. If you are hardware challenged, and don't mind flying without the FAA mandated safety equipment, you could certainly improve performance a bit, if you disabled the pid tracking part of this add-on data. All you lose is the ability to figure out which interface handler locked up queueing the packet. Look in util.c for the _accessMutex(), _releaseMutex() and _tryLockMutex() functions. It would also be possible to put this into thread-specific data (to save the getpid() call). That change falls out as part of the ntop watchdog I've been working on for post 2.3. Off hand, I'm not sure where the time() call you're refering to is. ntop tries to use the pcap packet timestamp if possible. In the back of my mind, I think there's some code that checks if the timestamp is increasing and uses the time(NULL) call if it is not. That's especially important as Luca's tryLock change makes it much more likely for ntop to handle packets out of order. -----Burton ---------- Original Message ---------------------------------- From: Chris Turbeville <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Thu, 4 Sep 2003 23:35:42 -0500 (CDT) >In watching ntop run on my sparc with a ~40Mbps (7500pkt/sec) or so stream >I noticed a large number of system calls and pretty sluggish performance. >Memory isn't an issue but a truss showed it calling time and getpid >thousands of times. Near as I can tell the tryLockMutex in the per packet >mutex is calling getpid forevery packet. As I understand it ntop is >threaded with the only fork being for static web serving so why do we >need to check the pid so much? Also the time call seems to be just for >accounting purposes so why not put it in the ifdef debug wrappers? >Just trying to squeeze some performance out of my old sparc hardware. >-Chris >BTW If anyone cares it a dual (soon to be quad) 400MHz ultrasparc with >2gig and a ZyNX quad 100meg ether. >-- >[EMAIL PROTECTED] Chris Turbeville NTT/VERIO > Send mail with subject "send PGP Key" for PGP 6.5.2 Public key >_______________________________________________ >Ntop-dev mailing list >[EMAIL PROTECTED] >http://listgateway.unipi.it/mailman/listinfo/ntop-dev > ____________________________________________________________ Free 20MB Web Site Hosting and Personalized E-mail Service! Get It Now At Doteasy.com http://www.doteasy.com/et/ _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
