With the recent addition of the ability to set the buffers size for UDP and TCP sockets in 5.2, it seems like a good time to revisit the question of what the default value should be. The current behavior is to set them to 128k, which seems rather large. The rational, from the CVS log message:
- set SO_SNDBUF and SO_RCVBUF to 128Kb for newly-opened UDP sockets, to enable large PDUs to be sent and received. Some implementations default very low (Solaris 2.7 8Kb, Linux 2.4 64Kb).
The other important bit of information about socket size is that if affects the number of packets that can be received while a process is busy. The original author of the patch to allow increased buffers sizes was motivated by the fact that his snmptrapd was losing packets due to an insufficient receive buffer.
The new patch allows on to set independent buffer sizes for client vs server, and send vs receive. Given that SNMP_MAX_PDU_SIZE is less than 64k, a default buffer size of 128k seems excessive.
I suggest that:
1) snmpd and snmptraps both set the default receive buffers size to at least 128k, if not more, to minimize the changes of missing packets.
2) if no buffer size is specified, that the default be to use the default size specified by the OS. I'm guessing that the average PDU is pretty small (<1k), so the OS defaults are probably very safe.
Thoughts, opinions and arguments welcomed.
I may be overacting. You get to decide.
Are there not O.S. platform specific mechanisms for buffer tuning
that exist already ? Would those be better documented and well known ?
Would network administrators know the interactions of application specific tuning with the system level tuning ?
Would Net-SNMP users, in general very nice people, be also crack network programmers or administrators that can triage tuning inefficiences ? A number of them are. Would Net-SNMP developers given incomplete information provide sufficient guidance to assist in the successful deployment of some performance tuned application scenario ? I can see that happen.
With the greatest respect to the author of the patch, I think the default should be "do not set this". Better yet, I think the patch should be removed, and left in the "This Works For Me" kind of patches that we collect, and not incorporated into the project.
If the community really wants the patch, well, I will reconsider my arguments in that light.
Other ways more pertinent to this discussion may be to reconsider how some of the logic is implemented.
I think there are several well thought low impact performance improvements that are somewhere in the bug, patch, mail archive. [Finding them is not a trivial exercise!]
This one, for instance claims improved response to traps through more efficient use of the snmp_oid_compare() call.
Patch 1022941 Speed up adding a row to a table
There may be a number of other methods worth dis-covering.
Best Regards, -Mike Slifcak
------------------------------------------------------- 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
