On Thu, 22 Jul 2010 08:21:40 +0100 Dave wrote:
DS> > - try convincing the IETF to re-open the evolution of SNMP working group
and
DS> > define a standard for OID compression and bulk data transfer. ;-)
DS>
DS> - try experimenting with the provisional implementation that was developed
DS>
On 21 July 2010 17:10, Robert Story wrote:
> On Wed, 21 Jul 2010 08:35:56 +0100 Dave wrote:
> DS> On 21 July 2010 07:42, Prakash wrote:
> DS> > Is there any options to optimize the snmp bandwidth,
> DS> > because we are using a large table with 122 rows and 21 columns.
> DS> > When I use snmpwalk
On Wed, 21 Jul 2010 08:35:56 +0100 Dave wrote:
DS> On 21 July 2010 07:42, Prakash wrote:
DS> > Is there any options to optimize the snmp bandwidth,
DS> > because we are using a large table with 122 rows and 21 columns.
DS> > When I use snmpwalk on that table it consuming 21 kbps.
DS>
DS> - try
On 21 July 2010 07:42, Prakash wrote:
> Is there any options to optimize the snmp bandwidth,
> because we are using a large table with 122 rows and 21 columns.
> When I use snmpwalk on that table it consuming 21 kbps.
- try using 'snmpbulkwalk'
- try using 'snmptable'
- try using 'snmp
Is there any options to optimize the snmp bandwidth,
because we are using a large table with 122 rows and 21 columns.
When I use snmpwalk on that table it consuming 21 kbps.
Please help me to reduce the bandwidth.
Regards,
Prakash Raju
On Fri, 30 Sep 2005 16:06:10 -0400 shuki wrote:
SS> Hi Robert, thanks for the answer.
SS> Any idea when the pass-thru template is going to be available?
As soon as someone gets motivated enough to write it! I'm willing the help,
but don't have the time myself, at the moment.
--
NOTE: messages se
On Mon, 03 Oct 2005 09:48:04 +0100 Dave wrote:
DS> > This is exactly what the row_merge helper is for. It will call the table
DS> > handler once for each index, instead of once per varbind.
DS>
DS> Errr... no - that's not true. (Sorry, Robert!)
D'oh! I was thinking of the original iterator cod
> here is the code maybe something will ring a bell.
H
I'm not sure that really qualifies as the "trivial example"
that I suggested you try.
I'll look at it properly on Monday.
But one thing strikes me immediately.
The heart of the relevant processing is the call:
> if(!extract_if
atus' value.
* May need to use 'memcpy'
*/
table_entry->ifAdminStatus =
table_entry->old_ifAdminStatus;
break;
}
}
break;
case MODE_SET_COMMIT:
break;
#
On Fri, 2005-10-07 at 11:56 -0400, sasson, shuki wrote:
> I have tried snmpget to query a get request and snmpwalk for getNext.
In which case I can't explain your results.
However, as I said - I've just tried this with a simple
table of my own, and it *does* work as expected.
I suggest you try ag
configuration file for travesing
large tables. --- Does Net-SNMP fit to real time environment?
On Fri, 2005-10-07 at 11:23 -0400, sasson, shuki wrote:
> I have tried to apply the netsnmp_register_table() as you suggested in
> previous email.
> However the table_handler was not called for any Ge
On Fri, 2005-10-07 at 11:23 -0400, sasson, shuki wrote:
> I have tried to apply the netsnmp_register_table() as you suggested in
> previous email.
> However the table_handler was not called for any Get Request for a table
> entity I'll be thankful if you can
> verif
appy to try it again.
Thanks again,
Shuki
-Original Message-
From: Dave Shield [mailto:[EMAIL PROTECTED]
Sent: Friday, October 07, 2005 11:15 AM
To: sasson, shuki
Cc: [email protected]
Subject: RE: Cannot find an adquest mib2c configuration file for travesing
large table
On Fri, 2005-10-07 at 10:48 -0400, sasson, shuki wrote:
> Hi all, I managed to "create" myself a pass through interface to traverse
> big tables. Basically it is based on table iterator template.
> Even after applying this fix I see 35% degradation in performance
> compares to another agent imple
ists.sourceforge.net
Subject: Re: Cannot find an adquest mib2c configuration file for travesing
large tables.
On Wed, 28 Sep 2005 16:23:28 -0400 shuki wrote:
SS> will be a single function all instead hundred of thousands as it is with
SS> the MFD and the Iterator.
Early versions of MFD defa
On Fri, 2005-09-30 at 15:48 -0400, Robert Story wrote:
> DS> This [interpreting indexes]
> DS> is done for each varbind separately (since a single request may
> DS> well refer to several different rows). That's the purpose of the loop
> DS> through the 'requests' parameter - each entry in this li
On Fri, 30 Sep 2005 10:00:11 +0100 Dave wrote:
DS> > I suspect that I have to look to the variable bindings to extract the
DS> > tables indexes.
DS>
DS> No.
DS> These indexes will already have been extracted by the 'table' helper.
DS> You can use 'netsnmp_extract_table_info()' to retrieve the re
On Fri, 30 Sep 2005 11:43:43 -0400 shuki wrote:
SS> I have tried to look at things with a debugger and:
SS>
SS> a.) The ifEntry handler is not called for a GET it is called for a GETNEXT.
When you are dealing with the indexes yourself, you have to deal with the GET
and GETNEXT case. We can only d
On Wed, 28 Sep 2005 16:23:28 -0400 shuki wrote:
SS> will be a single function all instead hundred of thousands as it is with
SS> the MFD and the Iterator.
Early versions of MFD defaulted to an iterator style wrapper, but the current
code is based on the idea of caching the data, and a single routi
: Cannot find an adquest mib2c configuration file for travesing
large tables.
On Wed, 28 Sep 2005 16:23:28 -0400 shuki wrote:
SS> will be a single function all instead hundred of thousands as it is with
SS> the MFD and the Iterator.
Early versions of MFD defaulted to an iterator style wrappe
To: sasson, shuki
Cc: [email protected]
Subject: RE: Cannot find an adquate mib2c configuration file for travesing
large tables.
On Thu, 2005-09-29 at 17:15 -0400, sasson, shuki wrote:
> Hi David, I have tried to follow your instructions.
> I found that the handler function..
On Thu, 2005-09-29 at 17:15 -0400, sasson, shuki wrote:
> Hi David, I have tried to follow your instructions.
> I found that the handler function
> is called only by GETNEXT...
It shouldn't be. This handler ought to be called for both
GET and GETNEXT requests.
Dave
---
On Thu, 2005-09-29 at 14:54 -0400, sasson, shuki wrote:
> You suggest I will change the following call:
> netsnmp_extract_table_row_data(request);
>
> With a call to the external DB to retrieve the information. So this
> means that the indexes for that call should be retrieved from request
Correc
Hi David, I have tried to follow your instructions. I found that the handler
function:
/** handles requests for the ifTable table */
int
ifTable_handler(netsnmp_mib_handler *handler,
netsnmp_handler_registration *reginfo,
netsnmp_agent_request_info *reqinfo,
Hi David, I am looking seriously at this possibility. I still have some
questions:
You suggest I will change the following call:
netsnmp_extract_table_row_data(request);
With a call to the external DB to retrieve the information. So this means
that the indexes for that call should be retrieved fr
Hi David, thanks for the answer I will look at the template and will let you
know.
When I said hundred of thousands of function calls I referred to run time
function calls by the Net-SNMP for each and every row in the huge table.
(That's how the iterator template conducts the search).
Thanks,
Shuk
26 matches
Mail list logo
