Path: utzoo!attcan!uunet!bu.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!ukma!usenet.ins.cwru.edu!eagle!data.nas.nasa.gov!noc.arc.nasa.gov!gutierre From: gutierre@noc.arc.nasa.gov (Robert Michael Gutierrez) Newsgroups: comp.sys.proteon Subject: Re: Overview Problem Message-ID: <1990Oct19.031616.9403@nas.nasa.gov> Date: 19 Oct 90 03:16:16 GMT References: <9010170358.AA02833@umd5.UMD.EDU> <9010171142.AA08697@sayshell.umd.edu> Sender: news@nas.nasa.gov Reply-To: gutierre@noc.arc.nasa.gov (Robert Michael Gutierrez) Organization: NASA Science Internet - Network Operations Center. Lines: 53 [I originally wrote this to the p-4200 distribution list, but it never made it here] klong@umd5.umd.edu (Kim Long) writes on the P-4200 dist. list: >I'm writing on behalf of the SURAnet NOC in regard to a problem >we are experiencing with the Overview Network Monitoring package. NASA Science Internet Network Operations uses the same platform currently to monitor AMES-NET (NSIPO) from the Ames Research Center. We are also experiencing problems with that platform. The current problem we have had is that all of the buffers on the device driver for PC-TCP seem to fill up, causing a transmission lockup on the ethernet interface. The subsequent lockup causes Overview to status all the nodes as unreachable (red nodes and red lines). We can exit the program (slowly) though, but this does not free up the buffers. A warm reboot is needed to clear the buffers at this point. We exchanged the complete box out (except the EGA display card...the replacement PC didn't seem to have a display card), but we still have the same problem. >Presently, we have 116 nodes that we query using Overview. >The cycle time is set to 55 and the resp time is set to 1.5. We have Overview Version 1.00 (dated 12/88...is this the only version ever made!?!) and PC-TCP Version 2.03. We currently have 54 nodes on 1 level (we only use one 'cloud' [member] to group 4 nodes). Of those nodes, 52 are SNMP. Our query times are set fairly high (20 seconds on a response of 2.0...this is the only way to catch framing and CRC hits). >Would you have any idea as to the cause of the problem? Would a math >co-processor take some of the load off? Thanks for your input. I thought about this angle, but it would only work if the Overview program was compiled with the appropriate options. Was the intention of Overview only to support small networks? Is it incapable of handling anything over "X" amount of nodes? (Our magic number seemed to have been around 35 nodes). It was a platform that performed fine for the initial small network we previously had, but as nodes were added, it was apparent that it was not going to be as flexible as we were expecting. We are trying to implement SunNet Manager, but that`s a whole 'nother can of worms right now. Robert Michael Gutierrez NASA Science Internet - Network Operations Center.