Has anybody tried compiling ntop under SFU? Now that it's a free download, it might be more robust than the emulation libs. The Interix subsystem it uses runs parallel to the Win32 subsystem rather than on top, so mapping Unix calls to Win32 calls that don't really match is unnecessary. That said, I haven't yet spent enough time with it to get used to the inevitable quirks.
On Wed, 2004-03-10 at 09:15, Burton M. Strauss III wrote: > 3.0's -x and -X switches help there - although they're crude (just throw > away data over the limit), it does allow you to limit yourself to the > 'right' value for hosts and sessions. > > The reason you find 2.2c stable is because you're using sticky hosts. > Without that, you would be doing the hash table resize, and the shrink was > often the cause of problems (wild pointers). > > Win32 is an odd duck. Libpcap is about even, the basic packet capture > (TCP/IP stack) is more robust under Windows, but a lot of add-on code (e.g. > RRD) may be less well tested. Some of the other shim type libraries we use > to create a common programming environment may also have issues - that's > ultimately what sunk MinGW. These things are all but impossible to find, > when you have to run for days before the failure (and the debugger changes > the memory allocation and threading model so you're really not running the > same code...) > > > As always, YMMV... > > -----Burton > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Mark > > Gibbons > > Sent: Wednesday, March 10, 2004 10:50 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [Ntop] How much uptime can you get? > > > > > > My RRD comment specifically related to the win 32 version - sorry > > if this was confusing. > > > > On windows, 3.0 is MUCH more stable than 2.2 ever was. > > > > On linux - well on redhat 8.0 we have never really had an uptime > > issue with either 2.2 or 3. As I said it just goes on and on > > assuming memory is not an issue. We run with Sticky hosts, local > > only. In this context the only time we have problems is if a new > > node added to the net has a worm virus and it tries contacting > > the full range of a 10. Class A subnet. Having hosts as sticky > > means that we soon run out of memory when we have an errant worm > > program - at least we know we have a problem pretty quickly ;-) > > > > Mark > > > > > > > > -----Original Message----- > > From: Stephan Knabe [mailto:[EMAIL PROTECTED] > > Sent: 10 March 2004 4:33 > > To: [EMAIL PROTECTED] > > Subject: RE: [Ntop] How much uptime can you get? > > > > > > On Wed, 10 Mar 2004, Nick Fisher wrote: > > > > > > Which platform? > > > Doh! Sorry, I'm running it on a few different gentoo linux machines. > > > > > > > Linux - ntop goes on for weeks as long as you do not exhaust > > > > memory (too many hosts) > > > Intresting.... so ntop bombs when it needs more resources and can't have > > > them? > > > > No it gets killed by the kernel (out of memory). I saw this happen on a > > host with 256 MB RAM and 500MB Swap, when more than 50000 hosts were4 > > stored. Using a box with 2 GB RAM it needs a maximum of about 300 MB. > > > > > > Windows - 4 hours on 2.2 is about right. With 3.0Pre1 we get up > > > > to about 22 Hours > > > OOOooo.... is 3 more stable on Win32 or just in general? Perhaps it uses > > > less resources? > > > > > > > Usually uptime increases if you switch the RRD plugin OFF !?! > > > Buh? Let me get this straight.... ntop in general is supposed > > to work getter > > > without rrd? Turning on rrd was the only way I got ntop to run > > for over 6 > > > hours. Could the rrd plugin perhaps reduce resource usage? > > > > > > > I do not see this. I run it with rrd-plugin for a few weeks. I > > only restarted it to read a new protocol list. Actually I have an uptime > > of ca. 20.5 days. I use a CVS version from january, 5th. > > > > regards > > > > Stephan Knabe > > _______________________________________________ > > Ntop mailing list > > [EMAIL PROTECTED] > > http://listgateway.unipi.it/mailman/listinfo/ntop > > _______________________________________________ > > Ntop mailing list > > [EMAIL PROTECTED] > > http://listgateway.unipi.it/mailman/listinfo/ntop > > > > _______________________________________________ > Ntop mailing list > [EMAIL PROTECTED] > http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop
