nv-l
[Top] [All Lists]

RE: [nv-l] Status Polling

To: "'nv-l@lists.us.ibm.com'" <nv-l@lists.us.ibm.com>
Subject: RE: [nv-l] Status Polling
From: "Evans, Bill" <Bill.Evans@hq.doe.gov>
Date: Fri, 24 Jun 2005 16:49:45 -0400
Delivery-date: Fri, 24 Jun 2005 21:50:51 +0100
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com

Your description was much clearer than mine. 

        "NetView compensates by its geometrically increasing waits on retries" 

Translation: "Every retry doubles the timeout value" = "a geometric progression". 

The NetView for Administrators class also used to warn attendees not to set the retries and wait time so high that the total exceeded the polling cycle.  Your example of 7 retries with 1 second timeout would exceed a two minute polling cycle.   NetView Administration is not for the arithmetically challenged or those who don't appreciate the relationships among the tuning values. 

Thanks for clearing up my muddy wording.

Bill Evans



-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com] On Behalf Of Barr, Scott
Sent: Friday, June 24, 2005 4:28 PM
To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] Status Polling

One warning about retries.

Each time you retry, the SNMP or ping, netmon appears to double the
timeout value. So, if you set 7 retries with 1 second time out, you get
1, 2, 4, 8, 16, 32, 64 seconds timeout values.

If you have a lot of nodes this way, that can cause more issues than it
solves.

One caveat, I've been doing TEC/Framework/ITM for a while so the way
netmon behaves may have changed some time ago.


<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web