Date: Tue, 30 Jun 1998 22:37:08 -0700 (PDT) From: Marc Slemko <marcs@znep.com> To: Bill Fenner <fenner@parc.xerox.com> Cc: freebsd-hackers@FreeBSD.ORG, jamin@eecs.umich.edu Subject: Re: client-server problem Message-ID: <Pine.GSO.3.96.980630223011.12884C-100000@redfish> In-Reply-To: <199807010409.VAA06201@mango.parc.xerox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 30 Jun 1998, Bill Fenner wrote: > #define MHLEN (MLEN - sizeof(struct pkthdr)) /* data len w/pkthdr */ > > - -#define MINCLSIZE (MHLEN + MLEN) /* smallest amount to put in cluster */ > +#define MINCLSIZE (MHLEN) /* smallest amount to put in cluster */ > #define M_MAXCOMPRESS (MHLEN / 2) /* max amount to copy for compression */ ISTR that there was some problem when someone (I?) suggested this workaround before, in addition to what you mention. Hmm. Maybe it was just dg thinking he remembered something breaking, but he wasn't sure what. David Borman said: >I know what problem you are referring to, but it is not as you describe >it. For a non-atomic protocol (like TCP) sosend() will allocate a >cluster if the data won't fit in the mbuf, even if it is over by only >one byte. This puts a small amount of data into a cluster. It >doesn't take very many of these small writes until sb->sb_mbcnt bumps >into sb->sb_mbmax, long before sb->sb_cc hits sb->sb_hiwat. So, you >get a socket send buffer without much data to send, which can't accept >any more data from the user. You wind up waiting for the delayed ACKs >from the remote side to clear out buffer space, but it is never enough >to allow you to get 2 full packets out to get past the delayed ACKs! >The problem is that sbcompress() does not compress cluster mbufs, to >avoid excessive data copies. I've modified sbcompress() (in the next >release of BSD/OS) to allow cluster mbufs to be compressed, provided >that all the data can be copied and there is no more than 1/4 of a >cluster to copy. This change allows enough data to be copied down >from the user to get out 2 full packets and thus get past the delayed >ACKs. The benchmark will still run slow because of the tiny writes, >and the extra data copies, but at least it no longer runs an order or >two of magnitude slower than really tiny writes (<= the size of an mbuf). about the problem. I don't have the full thread, since I'm in SF and don't have access to my machine at home. It may have been on nanog (? most odd discussions are there). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.96.980630223011.12884C-100000>