From owner-freebsd-net Sun Nov 14 19: 0:35 1999 Delivered-To: freebsd-net@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id B1AD814BF8 for ; Sun, 14 Nov 1999 19:00:30 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id WAA03998; Sun, 14 Nov 1999 22:00:24 -0500 (EST) (envelope-from wollman) Date: Sun, 14 Nov 1999 22:00:24 -0500 (EST) From: Garrett Wollman Message-Id: <199911150300.WAA03998@khavrinen.lcs.mit.edu> To: Luigi Rizzo Cc: freebsd-net@FreeBSD.ORG Subject: Re: FreeBSD networking problems In-Reply-To: <199911121435.PAA05210@info.iet.unipi.it> References: <199911102211.QAA12891@cs.rice.edu> <199911121435.PAA05210@info.iet.unipi.it> Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > related issue -- kern.ipc.maxsockbuf can also be a source of problem. > It bounds the gross amount of buffer space used by a socket -- this > means if you allocate a 2KB cluster and only use it to hold a small > packet (e.g. 512 bytes) your gross amount of buffer space is charged > the full 2KB and the kern.ipc.maxsockbuf limit might hit before > net.inet.tcp.sendspace (or however you override it with the > setsockopt() calls) Not quite. It's charged against the maximum mbuf size (sb_maxmb), which is sockbuf_waste_factor * sb_hiwat. This is an intentional trade-off between speed and memory wastage. (That doesn't mean it's not time to revisit this tradeoff; it just means that the original reasons still need to be considered.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message