From owner-freebsd-hackers Fri Aug 21 04:50:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA21976 for freebsd-hackers-outgoing; Fri, 21 Aug 1998 04:50:57 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bsd.synx.com (rt.synx.com [194.167.81.239]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id EAA21934 for ; Fri, 21 Aug 1998 04:50:25 -0700 (PDT) (envelope-from root@synx.com) Received: from synx.com (rn [192.1.1.241]) by bsd.synx.com (8.6.12/8.6.12) with ESMTP id MAA18508; Fri, 21 Aug 1998 12:48:23 +0100 Message-Id: <199808211148.MAA18508@bsd.synx.com> Date: Fri, 21 Aug 1998 13:48:21 +0200 (CEST) From: Remy NONNENMACHER Reply-To: remy@synx.com Subject: Re: Yard/FreeBSD problem (fwd) To: didier@omnix.net cc: hackers@FreeBSD.ORG, support@yard.de In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 21 Aug, Didier Derny wrote: Didier, In an unmodified kernel (prior to sysctlized delayed_ack), the delayed ack is always turned ON and the 101-207 bytes problem exists. TCP_NODELAY option helps the following way : case TCP_NODELAY OFF : T Application TCP-client TCP-server DBMS 0 write(...., 150) ---> packet(100) ---> packet(100) --> read()=100 | (delay 200ms) | ack <--- ack | packet(50) ---> packet(50) --> read()=50 | X read()= <---- packet(n) <--- packet(n)+ack <-- DB-reply(n) in the case, X= 200ms + epsilon (epsilon = neglected net+DBMS+internal processing time). case TCP_NODELAY ON : T Application TCP-client TCP-server DBMS 0 write(...., 150) ---> packet(100) ---> packet(100) --> read()=100 packet(50) ---> packet(50) --> read()=50 | X read()= <---- packet(n) <--- packet(n)+ack <-- DB-reply(n) Now, X=0 + epsilon = epsilon. If you still have the problem, we can be almost sure that TCP_NODELAY *is* OFF on one or either side. (I don't remember having been said that it must be ON on *either* side, BTW). Having the 101-207 bytes problem resolved needs a kernel modification and a great ancient aprobatur. If nobody takes on it, i offer to (as i run on it very often and it tires me). Anyway, this doesn't match your requirement of running with an old kernel version. Yard told you that they checked this TCP_NODELAY option against inheritence reseting. If a last chance Yard's code review doesn't reveal a problem (accepte()d, fork()ed, etc....), I offer to analyse two tcpdump trace of the same session: one from you and one took on the machine at Yard, then review kernel codes of the two FreeBSD versions you (and yard) use. (Note to Yard: thanks for supporting FreeBSD). RN. > Hi, > > I still have many problems with Yard/FreeBSD. > > I sent my programs / database to Yard last wednesday. > they did some testing on their version (FreeBSD 2.1.6) > It worked really fine except for a few slow down. > > (for him 350 seconds on a pentium 133) > > For me on 3.0-980594-SNAP and FreeBSD-2.2.5-STABLE > it's still unusable (I stopped the program after > 25 minutes on a Pentium II 333). > > We are writing some application that we are planning to > bundle with the Yard SQL engine. > > I can't imagine that I would have to tell my clients that > to run our applications they have to install the FreeBSD > source code and modify the kernel and rebuild it. > > do you have any idea on how we could definitively solve this > problem for 2.2.X and 3.X versions of FreeBSD ? > > -- > Didier Derny > didier@omnix.net > > > > ---------- Forwarded message ---------- > > I ran your program on our system and it shows a similar behaviour as you > describe. Below is the vmstat output, which indicates the hanging moments with > an idle time of > 50%. But these moments don't seem to be that awful. > In total your program took 350 seconds on a 133 MHz Pentium. > > If the reason for this behaviour is in fact the 100 byte problem mentioned by > one the FreeBSD guys, the only possible way to solve it would be to > set ack_delayed=1 (in the kernel?). Anything we at YARD can do? > > Regards > > Thomas Schonhoven > > PS.: I'll be back in office on Friday. > > > $ vmstat 2 200 > procs memory page disks faults cpu > r b w avm fre flt re pi po fr sr s0 s1 c0 f0 in sy cs us sy id > 3 0 0 79484 34224 9 1 0 0 6 0 2 0 0 0 233 54 13 1 0 98 > 2 0 0 83792 34088 19 9 0 0 0 0 21 0 0 0 350 4815 1618 66 29 5 > 1 0 0 83956 33924 21 4 0 0 0 0 3 0 0 0 341 5120 1736 67 31 1 > 2 0 0 84096 33772 22 18 0 0 0 0 3 0 0 0 333 4983 1686 72 26 2 > ...... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message