That all makes perfect sense, thanks for clearing that up for me!
On 11/30/06 3:00 , "InterMapper Discussion" <[email protected]> wrote: > InterMapper-Talk Digest - Thursday, November 30, 2006 > > Re: [IM-Talk] G4 OS X 10.2 probe > by "William W. Fisher" <[EMAIL PROTECTED]> > Re: [IM-Talk] G4 OS X 10.2 probe > by "Tex Clayton" <[EMAIL PROTECTED]> > > > ---------------------------------------------------------------------- > > Subject: Re: [IM-Talk] G4 OS X 10.2 probe > From: "William W. Fisher" <[EMAIL PROTECTED]> > Date: Wed, 29 Nov 2006 07:59:48 -0500 > > On Nov 28, 2006, at 6:14 PM, Rich Allen wrote: > >> the round trip time reported on the G4 Xserve probe (OS 10.2) is >> reported >> incorrectly. the reported time is 1000 times greater than actual; >> ie. 767 >> msec is reported for 0.767 msec. verified this using ping from >> several other >> boxes/OSs >> >> IM v4.5.1, probe is "Xserve G4 Probe" that was installed with IM > > The RTT of different probes will show deviation because different > probes measure different aspects of behavior. The ping probe should > have the smallest RTT; it just tests network connectivity of a single > packet. The XServe probe and other probes test network connectivity > and server responsiveness. (In some cases, there is a little overhead > within InterMapper itself.) When InterMapper probes an XServe (non- > Intel version), it makes a TCP connection to a specific port. Once > the connection is established, InterMapper issues a request for > information, then awaits the full response. As the response is > returned, InterMapper parses out the fields and populates variables > within the probe. The RTT of the XServe probe is thus the total time > it takes from connection establishment until status determination. > Since IM has to parse the entire response in an Xserve probe, it has > to download all of the data. > > When the status is determined varies for different probes. For > example, the status of an HTTP probe is determined when the "string > to match" is found. To measure the time it takes a web server to > *start* returning a page, specify start tag "<html>". To measure the > time it takes the web server to return the entire page, specify the > end tag: "</html>". With larger web pages, you'll see different > response times based on the string to match. > > One of my current issues with RTT alarming in 4.5.x is that the > default settings don't reflect differences between probes. > > Regards, > > Bill Fisher > Dartware, LLC > ---------------------------------------------------------------------- > > Subject: Re: [IM-Talk] G4 OS X 10.2 probe > From: "Tex Clayton" <[EMAIL PROTECTED]> > Date: Wed, 29 Nov 2006 08:09:05 -0500 > > > On Nov 28, 2006, at 8:16 PM, Jeff Kell wrote: > >>> On Tue, 28 Nov 2006 14:14 -0900, Rich Allen wrote: >>> >>> We're seeing what appears to be the same behavior with the Barracuda >>> HTTP probe under InterMapper 4.5.3 and Mac OS X 10.4.8. Round trip >>> times for our Barracuda 600 are in the thousands of msec as reported >>> by the probe, but pings to the Barracuda from a terminal window on >>> the >>> InterMapper server are typically < .5 msec round trip. >>> >> Our Barracuda *is* that slow to respond to HTTP. Try your web >> browser. > > The round-trip time that you are seeing for the Barracuda probe is > the time it takes to load the login page, login, and then load and > parse the status page. > > -Tex Clayton > Dartware, LLC > http://www.dartware.com > > > ---------------------------------------------------------------------- > End of InterMapper-Talk Digest > > ____________________________________________________________________ > List archives: > http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ > To unsubscribe: send email to: [EMAIL PROTECTED] > - hcir It always costs more to do nothing, than to do the right thing. ____________________________________________________________________ List archives: http://www.mail-archive.com/intermapper-talk%40list.dartware.com/ To unsubscribe: send email to: [EMAIL PROTECTED]
