From owner-freebsd-hackers Tue Jun 30 21:10:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA17313 for freebsd-hackers-outgoing; Tue, 30 Jun 1998 21:10:45 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alpha.xerox.com (omega.Xerox.COM [13.1.64.95]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id VAA17306 for ; Tue, 30 Jun 1998 21:10:42 -0700 (PDT) (envelope-from fenner@parc.xerox.com) Received: from mango.parc.xerox.com ([13.1.102.232]) by alpha.xerox.com with SMTP id <40657(2)>; Tue, 30 Jun 1998 21:09:33 PDT Received: from mango.parc.xerox.com (localhost [127.0.0.1]) by mango.parc.xerox.com (8.8.8/8.8.8) with ESMTP id VAA06201; Tue, 30 Jun 1998 21:09:26 -0700 (PDT) (envelope-from fenner@mango.parc.xerox.com) Message-Id: <199807010409.VAA06201@mango.parc.xerox.com> Date: Tue, 30 Jun 1998 21:09:25 PDT From: Bill Fenner To: To: Subject: Re: client-server problem Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ------- Blind-Carbon-Copy To: Yee Man Chan cc: freebsd-net@freebsd.org, fenner Subject: Re: client-server problem In-reply-to: Your message of "Mon, 29 Jun 1998 19:40:20 PDT." Date: Tue, 30 Jun 1998 21:09:25 -0700 From: Bill Fenner 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 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 ------- End of Blind-Carbon-Copy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message