I'd agree with that. Not only RTT is associated with ICMP in my head. If in the status window it could be mentioned some how or also be probed for ICMP RTT separately, it would be great.
If I want ICMP RTT, that correct, I can add another probe, but I don't want the same device showing up twice for a diff probe on the same map. Andrey -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Pat Storr Sent: Wednesday, January 09, 2008 3:01 PM To: InterMapper Discussion Subject: Re: [IM-Talk] Round trip weirdness I understand the ability to change thresholds on server-wide or on a per-map basis. However, I would like to be alerted if the RTT becomes abnormal. If I change the threshold to clean up my slow-to-reply SNMP devices, I won't know if "normal" devices have abnormal RTT reply. It seems to me that you'd have to be able to set threshold on a per-device basis to accomplish this goal. Maybe the ability to differentiate between ICMP RTT and SNMP RTT would be an option? On 1/9/08 2:46 PM, "Janice Losgar" <[EMAIL PROTECTED]> wrote: > Pat, > > If you are using InterMapper version 4.5 or higher, you can configure the > round-trip time thresholds for warning, alarm and critical alerts. You can > do this server wide using the Server Settings > Device Thresholds settings; > per-map using the Edit > Map Settings > Thresholds > Device settings; or > per-device, using the Set Info > Set Thresholds command. > > Regards, > > Janice Losgar > Dartware, LLC > > -----Original Message----- > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of Pat Storr > Sent: Wednesday, January 09, 2008 3:38 PM > To: InterMapper Discussion > Subject: Re: [IM-Talk] Round trip weirdness > > I will add my 2 cents here too. We monitor as much as we can via SNMP. > Some devices are slow to reply with the SNMP request, so the device displays > as yellow, orange or red on the map even though they are operating normally. > If we could change the threshold so they don't change colors based on SNMP > RTT it would keep our maps much cleaner. > > Pat > > > On 1/9/08 2:27 PM, "Steve Himebaugh" <[EMAIL PROTECTED]> wrote: > >> I vote for the name being misleading. RTT is firmly associated with ping > in >> my mind. >> >> FYI ... a ping RTT monitor in the Status Window would be nice. More > useful >> to me than the 'Round-trip time'/SNMP Response Time parameter. I would >> disable the 'Round-trip time' monitor if I had the option. >> >> Steve Himebaugh >> >> ----- Original Message ----- >> From: "Jakob Peterhänsel" <[EMAIL PROTECTED]> >> To: "InterMapper Discussion" <[email protected]> >> Sent: Wednesday, January 09, 2008 10:49 AM >> Subject: Re: [IM-Talk] Round trip weirdness >> >> >> >> I really can't see what's wrong with the name. It very directly tells >> you that this is the time it takes the Probe Used to enquire and get >> back a result. >> >> It does not say 'Ping RTT' does it? >> >> >> It's the same issue if you probe an Xserver for a lot of info - it can >> easily take 500-2500ms, but then you know that the server is slow in >> responding, or collecting the data. >> >> If you wanna know the Ping RTT.. set up a probe for it.. ;-) >> >> >> >> Jakob Peterhänsel >> >> "Be a part of the Love Generation - carry a smile, not a gun." >> - JP, May 2006 >> >> Email: [EMAIL PROTECTED] >> AIM: Marook >> Phone: +45 29687104 >> >> >> On 09/01/2008, at 17.31, Andrey Gordon wrote: >> >>> Hrm... >>> >>> Perhaps then the name of that value is misleading. I can't come up with > a >>> better one at this time, but something like 'Last request took: N sec' >>> would make more sense at a glance. >>> >>> Andrey >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected] ] On Behalf Of Janice Losgar >>> Sent: Wednesday, January 09, 2008 8:49 AM >>> To: 'InterMapper Discussion' >>> Subject: RE: [IM-Talk] Round trip weirdness >>> >>> Andrey, >>> >>> You can't compare the round-trip time of ping packets with an SNMP > probe. >>> For SNMP probes, round-trip time is calculated by the time it takes for >>> the >>> last packet sent to come back. In an SNMP probe with several variables, >>> we >>> send one request for all the variables. The round-trip time is the sum > of >>> the time it takes to retrieve all the information, which would be much >>> different than a simple ping request. >>> >>> Regards, >>> >>> Janice Losgar >>> Dartware, LLC >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Andrey Gordon >>> Sent: Tuesday, January 08, 2008 6:32 PM >>> To: InterMapper Discussion >>> Subject: [IM-Talk] Round trip weirdness >>> >>> I have map with a round trip time issue. I believe this is the only one, >>> but >>> I haven't looked that close for this before. >>> >>> You may notice from the paste of the status window that round trip time >>> to >>> the device is over 150ms according to intermapper >>> >>> Device Status >>> Name: v08-g1-axs-2 >>> DNS Name: v08-g1-axs-2.epicsys.com >>> Address: <snip> >>> Status: UP >>> Probe: SNMP - Cisco - Process and Memory Pool (port 161 SNMPv2c) >>> Up Time: 172 days, 19 hours, 54 minutes >>> SysName: v08-g1-axs-2.epicsys.com >>> Availability: 100 % (of 4 days, 1 hour, 45 minutes) >>> Packet Loss: 0.02 % (of 209673 total attempts) >>> Short-term Packet Loss: 0.0 % (of 100 last attempts) [Reset] >>> Recent Loss: 2 pkts at Jan 08, 15:06:31 >>> Round-trip time: 170 msec >>> Cisco Device Information >>> CPU Percent Busy: 16 % (of last 5 seconds) >>> Avg. CPU % Busy: 18 % (1 min.), 21 % (5 min.) >>> Available Processor Memory: 830841508 bytes >>> Available I/O Memory: 63583940 bytes >>> Last updated Jan 08, 17:29:23; interval: 5 seconds >>> >>> >>> >>> however: >>> >>> [EMAIL PROTECTED]:/~$ ping v08-g1-axs-2 >>> PING v08-g1-axs-2.epicsys.com (<snip>) 56(84) bytes of data. >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=0 ttl=254 >>> time=1.20 ms >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=1 ttl=254 >>> time=1.57 ms >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=2 ttl=254 >>> time=1.17 ms >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=3 ttl=254 >>> time=0.834 ms >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=4 ttl=254 >>> time=0.751 ms >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=5 ttl=254 >>> time=1.03 ms >>> 64 bytes from v08-g1-axs-2.epicsystems.com (<snip>): icmp_seq=6 ttl=254 >>> time=0.939 ms >>> >>> --- v08-g1-axs-2.epicsys.com ping statistics --- >>> 7 packets transmitted, 7 received, 0% packet loss, time 6005ms >>> rtt min/avg/max/mdev = 0.751/1.072/1.575/0.259 ms, pipe 2 >>> [EMAIL PROTECTED]:/~$ >>> >>> >>> Why is this happening? >>> >>> I'd like to mention that this device is not the only one that does it. >>> I'd >>> like to mention that netmon2 is the server running the intermapper. So, >>> intermapper thins the round trip time is 160ms, but CLI ping from the >>> same >>> box is 1ms. My routers in europe show up with 130ms on the intermapper. >>> >>> The devices that do produce this weird round trip time are all my 3005 >>> cisco >>> VPNc, two fwsm blades and the core internet access router. I understand >>> they >>> use tons more CPU cycles then the rest, but then why does my CLI ping >>> comes >>> back fine? >>> >>> ____________________________________________________________________ >>> List archives: >>> http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ >>> To unsubscribe: send email to: [EMAIL PROTECTED] >>> >>> ____________________________________________________________________ >>> List archives: >>> http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ >>> To unsubscribe: send email to: [EMAIL PROTECTED] >>> >>> ____________________________________________________________________ >>> List archives: >>> http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ >>> To unsubscribe: send email to: [EMAIL PROTECTED] >>> >> >> ____________________________________________________________________ >> List archives: >> http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ >> To unsubscribe: send email to: [EMAIL PROTECTED] >> >> >> ____________________________________________________________________ >> List archives: >> http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ >> To unsubscribe: send email to: [EMAIL PROTECTED] >> > > > ____________________________________________________________________ > List archives: > http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ > To unsubscribe: send email to: [EMAIL PROTECTED] > > ____________________________________________________________________ > List archives: > http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ > To unsubscribe: send email to: [EMAIL PROTECTED] > ____________________________________________________________________ List archives: http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ To unsubscribe: send email to: [EMAIL PROTECTED] ____________________________________________________________________ List archives: http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ To unsubscribe: send email to: [EMAIL PROTECTED]
