On Sun, 03 Oct 2004 09:39:52 -0400 Michael wrote: MJS> Robert Story (Coders) wrote: MJS> > The new patch allows on to set independent buffer sizes for client vs MJS> > server, and send vs receive. Given that SNMP_MAX_PDU_SIZE is less than MJS> > 64k, a default buffer size of 128k seems excessive. MJS> > MJS> > MJS> > I suggest that: MJS> > MJS> > 1) snmpd and snmptraps both set the default receive buffers size to at MJS> > least 128k, if not more, to minimize the changes of missing packets. MJS> > MJS> > 2) if no buffer size is specified, that the default be to use the MJS> > default size specified by the OS. I'm guessing that the average PDU is MJS> > pretty small (<1k), so the OS defaults are probably very safe. MJS> MJS> Are there not O.S. platform specific mechanisms for buffer tuning MJS> that exist already ?
Yes, for the default buffer size for the whole system. Some applications may have different needs. MJS> With the greatest respect to the author of the patch, MJS> I think the default should be "do not set this". It's not just about the patch. For the past 3.5 years, the default has set a fixed buffer size of 128k. From the tone of your message, I imply that you would eliminate this fixed size too (eg #2 in my list). MJS> I think the patch should be removed, and left in the "This Works For Me" MJS> kind of patches that we collect, and not incorporated into the project. I disagree here. I think it is very useful to be able to resize the buffers without having to patch the code. In particular, it's very useful for snmptrapd, which may receive lots of traps very quickly, and isn't particularly efficient about processing them. MJS> I think there are several well thought low impact performance MJS> improvements that are somewhere in the bug, patch, mail archive. MJS> [Finding them is not a trivial exercise!] MJS> MJS> This one, for instance claims improved response to traps through MJS> more efficient use of the snmp_oid_compare() call. MJS> MJS> Patch 1022941 Speed up adding a row to a table Good one! I'll be applying it shortly. Actually, it would probably be worth changing the table_data to use netsnmp_container, instead of a linked list. That would improve performance of walking large tables too. Maybe for 5.3. -- Robert Story; NET-SNMP Junkie <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp> Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-coders> You are lost in a twisty maze of little standards, all different. ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
