nv-l
[Top] [All Lists]

Re: [nv-l] udp_recvspace vs tcp_recvspace

To: Leslie Clark <lclark@us.ibm.com>
Subject: Re: [nv-l] udp_recvspace vs tcp_recvspace
From: James Shanks <jshanks@us.ibm.com>
Date: Wed, 16 Apr 2003 10:02:42 -0400
Cc: nv-l@lists.tivoli.com
Delivered-to: mailing list nv-l@lists.tivoli.com
Delivery-date: Wed, 16 Apr 2003 19:31:17 +0100
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
List-help: <mailto:nv-l-help@lists.tivoli.com>
List-post: <mailto:nv-l@lists.tivoli.com>
List-subscribe: <mailto:nv-l-subscribe@lists.tivoli.com>
List-unsubscribe: <mailto:nv-l-unsubscribe@lists.tivoli.com>
Mailing-list: contact nv-l-help@lists.tivoli.com; run by ezmlm
I guess I don't see the point.  Do you see this as "rate gate" mechanism? 
Isn't the OS just going to fill up that space as quickly as possible and 
then throw away what doesn't fit?  So how do you know there isn't 
something in there you want?  But it might reduce the rate of incoming 
traps though it seems risky to me.

MLM is a much better bet.  You add a new daemon to share he workload, 
because otherwise there is no controlled way to discard incoming traps you 
don't want.  Whatever  comes in trapd is still going to have to process it 
eventually.  And when he does they are going to go to nvcorrd, just like 
before.  Nobody's workload is reduced, unless you get a prior agent to 
restrict the flow.  Even if your gate works, it might still be a disaster 
if you later miss something important. 

James Shanks
Level 3 Support  for Tivoli NetView for UNIX and NT
Tivoli Software / IBM Software Group




Leslie Clark/Southfield/IBM@IBMUS
04/16/2003 08:44 AM

 
        To:     nv-l@lists.tivoli.com
        cc: 
        Subject:        [nv-l] udp_recvspace vs tcp_recvspace







For systems that are short of memory and being flooded with unsolicited
traps that cannot be turned off for a while, I wonder if this approach
would be appropriate: reduce the 'no' setting for udp_recvspace to
something rather smaller, but leave tcp_recvspace at the correct value.
Would this cause trapd to miss out on incoming traps, but still get all of
the Netview - generated ones? Trapd is handling the flood fine, but 
nvcorrd
can't keep up. Just wondering... My next suggestion is going to be an MLM
on the same box.

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
(248) 552-4968 Voicemail, Fax, Pager


---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)





---------------------------------------------------------------------
To unsubscribe, e-mail: nv-l-unsubscribe@lists.tivoli.com
For additional commands, e-mail: nv-l-help@lists.tivoli.com

*NOTE*
This is not an Offical Tivoli Support forum. If you need immediate
assistance from Tivoli please call the IBM Tivoli Software Group
help line at 1-800-TIVOLI8(848-6548)


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

Archive operated by Skills 1st Ltd

See also: The NetView Web