Date: Tue, 30 Jun 1998 21:09:25 PDT From: Bill Fenner <fenner@parc.xerox.com> To: Yee Man Chan <ymc@eecs.umich.edu> Cc: freebsd-net@FreeBSD.ORG, fenner@parc.xerox.com Subject: Re: client-server problem Message-ID: <199807010409.VAA06199@mango.parc.xerox.com> In-Reply-To: Your message of "Mon, 29 Jun 1998 19:40:20 PDT." <Pine.GSO.3.96.980629221622.1437A-300000@shivam.eecs.umich.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
This thread belongs on the freebsd-net mailing list. I've bcc'd -hackers, since it started there, but please follow up on the -net list. In message <Pine.GSO.3.96.980629221622.1437A-300000@shivam.eecs.umich.edu>you w rite: >Here is how the program performs under FreeBSD 3.0-CURRENT with different >n: >1-100 Very fast >101-207 Very Slow (This range is the strangest I've ever seen) >208-1024 Very fast (just like 1-100) This is an interaction between an optimization for large transfers (see http://www.kohala.com/~rstevens/vanj.88jul20.txt) which ends up interacting with the Nagle algorithm for small transfers. One solution is to simply switch to a cluster mbuf as soon as the transfer doesn't fit in a small mbuf: --- /sys/sys/mbuf.h Mon Aug 19 11:30:15 1996 +++ /tmp/mbuf.h Tue Jun 30 18:40:59 1998 @@ -52,7 +52,7 @@ #define MLEN (MSIZE - sizeof(struct m_hdr)) /* normal data len */ #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 */ /* This is arguably wasteful of memory, in which case the other solution is to undo the optimization when not using cluster mbuf's. The most straightforward way is probably to set atomic to 1 when top == 0 and resid < MINCLSIZE in sosend(). Both of these fixes are untested. >>1024 strange errors like unknown host or connection timedout This is because your code uses the stdio constant BUFSIZ to size its buffer, and when you use "-n" arguments larger than 1024, it starts overwriting parts of the stack. You probably shouldn't use a value like BUFSIZ to size buffers that you need to know the size of, or if you do, do some range checking to make sure that you don't overrun them. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807010409.VAA06199>