Just as a quick FYI. If "it is decided" to pull the patch then the network admins/system admins would not be able to tweak anything anymore, because the situation as it was "before the patch" reset both the send and receive buffer to 128K (hardcoded). That means, even before the patch all net-snmp apps were changing buffers to make at least the PDU fit in the OS assigned buffer.
If your suggestion is to remove all buffer handling code from net-snmp, then that might leave us with the situation that a user will only get an 8k buffer (default on Solaris, as mentioned by Robert). In that case snmptrapd would simply not be able to receive traps more than 8k, and it wouldn't take a lot of traps before they get lost in the UDP stack (for snmptrapd). Furthermore, in case a user is smart enough he has encountered a buffer issue (and therefore he missed traps) then the network/sysadmin would only be able to change the default buffer size os a system wide setting. So in case the admin changes the UDP default buffer size to 128K by default, every process that creates a UDP socket would end up with 128K of kernel memory... The question would remain: how can we satisfy the administrator who wants a big receive buffer for snmptrapd (because those are network-buffer demanding applications), but use the system default for all the rest of the UDP sockets ? I think the patch is the only way to give an administrator that flexibility - and I'm not saying that because I happen to write the patch ;-) Of course if anyone can think of a way to only give a certain process a bigger send/receive buffer (and not as a system wide setting), then it would definitely be interesting to check it out as an alternative. Cheers, -- Geert PS : Would love to see patch 1022941 added too ! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael J. Slifcak Sent: Sunday, October 03, 2004 3:40 PM To: [EMAIL PROTECTED] Cc: John Naylon Subject: Re: default sock buffer size: what should it be? Robert Story (Coders) wrote: > 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 ------------------------------------------------------- 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
