[2002/10/11 09:09:23] #net-snmp <TrogL> hey kewl - I duplicated the diskio 20 filesystems bug
[2002/10/11 09:10:41] #net-snmp <wdebruij> oh, now I am here. I have a small question. As far as I understand the input pdu (for instance to snmp_sync_response) is reused as output. Can I also reuse the output for a new input pdu, instead of having flush the output and create a new input. If so, does this speed up the work?
[2002/10/11 09:10:48] #net-snmp <wdebruij> take your time ;)
[2002/10/11 09:11:11] #net-snmp <wes> yes you can.
[2002/10/11 09:11:54] #net-snmp <wdebruij> is it ok to simply remove the variables and rewrite the entries in the struct? Or should I use a specific function?
[2002/10/11 09:14:16] #net-snmp <wes> no you can do it yourself if you want. the functions just do the dirty work for you (watching out for locally used oid and value buffers, allocating larger ones if needed, ...)
[2002/10/11 09:14:56] #net-snmp <wdebruij> I'll use the supplied functions then. Hopefully it will clear off another millisecond or so. Thanks
[2002/10/11 09:15:55] #net-snmp <wes> if you're worried about timing, you might try turning on the cache I implemented but have it disabled at the moment since it's new.
[2002/10/11 09:16:10] #net-snmp <wes> assuming you're using 5.0.6?
[2002/10/11 09:17:07] #net-snmp <wdebruij> I used 5.0.3, I only noticed a never version came out when I entered this chat. Cache isn't useful for me `though.
[2002/10/11 09:17:22] #net-snmp <wes> it speeds up the agent by about a factor of 2-3
[2002/10/11 09:17:44] #net-snmp <wes> It's not the type of cache you're thinking about (it's not a data cache... It's internal agent stuff)
[2002/10/11 09:19:38] #net-snmp <wdebruij> by the way, from the tests I ran so far it seemed that opening a session takes up the bulk of the processing time. With snmpget it cost about 1.3 ms for a single request, while setting up the connection took ~320 ms. I don't know if you care, just so you know
[2002/10/11 09:20:27] #net-snmp <wes> what snmp version?
[2002/10/11 09:20:41] #net-snmp <wes> there is a lot going on in session opening.
[2002/10/11 09:20:50] #net-snmp <wdebruij> 5.0.3
[2002/10/11 09:21:03] #net-snmp <wes> no, i mean which version of SNMP? v1, v2c, or v3?
[2002/10/11 09:21:10] #net-snmp <wdebruij> oh 2c
[2002/10/11 09:21:12] #net-snmp <wes> Ah.
[2002/10/11 09:21:32] #net-snmp <wdebruij> I would image 3 to be even slower, with the encryption and all
[2002/10/11 09:21:41] #net-snmp <wdebruij> but I haven't tried that
[2002/10/11 09:22:37] #net-snmp <wes> yep.
[2002/10/11 09:22:40] #net-snmp <wes> it will be
[2002/10/11 09:22:44] #net-snmp <wes> key calculation takes a bit too
[2002/10/11 09:32:34] #net-snmp <TrogL> hmm where would I find ORACLE mibs?
[2002/10/11 09:35:22] #net-snmp <wes> google?
[2002/10/11 09:35:26] #net-snmp <wes> oracle's web site?
[2002/10/11 09:35:30] #net-snmp <wes> beats me!
[2002/10/11 09:36:46] #net-snmp <TrogL> ok i found some on somix - how do I tell if they're usable with our ssytems?
[2002/10/11 09:39:13] #net-snmp <TrogL> sorry not to RTFM, but I'm on horrendous deadline
[2002/10/11 09:40:19] #net-snmp <TrogL> is copying them to /usr/local/share/snmp/mibs sufficient? or do I have to do something to get them recognized?
[2002/10/11 09:43:48] #net-snmp <wes> by default they're not read in.
[2002/10/11 09:44:07] #net-snmp <wes> see http://www.net-snmp.org/tutorial-5/commands/mib_options.html
[2002/10/11 09:44:20] #net-snmp <TrogL> 404
[2002/10/11 09:44:53] #net-snmp <TrogL> gotit
[2002/10/11 09:58:33] #net-snmp <TrogL> Unliked OID in ORANAME-MIB: oracle::= { enterprises 111} - is this fatal?
[2002/10/11 09:59:01] #net-snmp <rstory> add enterprises to the IMPORTS section of the mib file
[2002/10/11 10:14:41] #net-snmp <wdebruij> is seems that upon PDU creation variable_list isn't initialized to NULL. This would be nice (at least for me), since it would give a simple check whether any variables exist or not.
[2002/10/11 10:15:44] #net-snmp <wdebruij> varbind_release does seem to depend on it not being NULL though
[2002/10/11 10:16:32] #net-snmp <wdebruij> does this mean snmp would crash when doing a varbind_release on a newly created pdu? I can check it if you don't know
[2002/10/11 10:17:48] #net-snmp <rstory> hmm.. how are you creating the pdu? we usually use calloc for memory, which should null out all vars
[2002/10/11 10:18:37] #net-snmp <wdebruij> well, I'm not overriding pdu_create just yet. I was thinking about it and in pdu_create (version 5.0.3 by the way) I don't see variable_list initialized
[2002/10/11 10:18:57] #net-snmp <wdebruij> that's precisely what I mean
[2002/10/11 10:20:56] #net-snmp <rstory> but the memory is calloc'ed, which inits all memory to 0, so variable_list will be null.
[2002/10/11 10:21:28] #net-snmp <wdebruij> is that so? well then, sorry for the remark. I never used calloc before, just malloc
[2002/10/11 10:21:42] #net-snmp <wdebruij> which frequently resulted in unnecessary coredumps ;)
[2002/10/11 10:44:13] #net-snmp <wdebruij> can I just throw in one last question?
[2002/10/11 10:44:39] #net-snmp <TrogL> ACTION is all ears
[2002/10/11 10:45:13] #net-snmp <wdebruij> Thanks! in the documentation it snmp_api.c it is said that you have to free the response pdu. When I do this in my callback function (using async_send) the system crashes
[2002/10/11 10:45:21] #net-snmp <wdebruij> should I not free the pdu here?
[2002/10/11 10:49:25] #net-snmp <wes> no you should.
[2002/10/11 10:49:36] #net-snmp <wes> assuming that the operation is NETSNMP_CALLBACK_OP_RECEIVED_MESSAGE
[2002/10/11 10:49:43] #net-snmp <wes> (otherwise, no!)
[2002/10/11 10:52:16] #net-snmp <wdebruij> it is NETSNMP_CALLBACK_OP_RECEIVED_MESSAGE. I'll try to figure out what it is I'm doing wrong since a free in my callback causes a sigsev. Thanks
[2002/10/11 10:57:07] #net-snmp <wdebruij> ACTION 's food is about ready. It's time to go. Good luck with your work
--> wes has joined #net-snmp
--> rstory ([) has joined #net-snmp
[2002/10/11 13:12:38] #net-snmp <ua> ACTION & bbl
--> wes (~) has joined #net-snmp
--> df () has joined #net-snmp
--> hampa (~) has joined #net-snmp
--> dbon (~) has joined #net-snmp
--> benr (~) has joined #net-snmp
--> wes (~) has joined #net-snmp
--> uathome (~) has joined #net-snmp

Powered by: