From owner-freebsd-hackers Wed Aug 19 00:19:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id AAA03488 for freebsd-hackers-outgoing; Wed, 19 Aug 1998 00:19:38 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from omnix.net (omnix.net [194.183.217.130]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id AAA03483 for ; Wed, 19 Aug 1998 00:19:36 -0700 (PDT) (envelope-from didier@omnix.net) Received: from localhost (didier@localhost) by omnix.net (8.8.7/8.8.7) with SMTP id HAA25420; Wed, 19 Aug 1998 07:18:53 GMT (envelope-from didier@omnix.net) Date: Wed, 19 Aug 1998 09:18:53 +0200 (CEST) From: Didier Derny To: Remy NONNENMACHER cc: dg@root.com, hackers@FreeBSD.ORG, support@yard.de Subject: Re: Yard/FreeBSD Problem (fwd) In-Reply-To: <199808171803.TAA24662@bsd.synx.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 17 Aug 1998, Remy NONNENMACHER wrote: > > I think i got the point. Didier sent me a tcpdump trace of the exchange > beetwen the client and the server. The protocol uses a lot of small > packets flowing back and forth, so ack_delayed=1 would be a good thing. > Unfortunetly, sometime (ie, 3 time in the trace), the protocol > encountered the 100 bytes syndrome. Precisely, the application wrote > 163 bytes, the data base replied by 119 bytes and the application wrote > 105 bytes. Here are fragments : > > 13:16:24.147494 1035 > yardsql: P 401:501(100) ack 70 win 17280 > 13:16:24.232584 yardsql > 1035: . ack 501 win 17280 > 13:16:24.232629 1035 > yardsql: P 501:564(63) ack 70 win 17280 > 13:16:24.234125 yardsql > 1035: P 70:170(100) ack 564 win 17280 > 13:16:24.432584 1035 > yardsql: . ack 170 win 17280 > 13:16:24.432624 yardsql > 1035: P 170:193(23) ack 564 win 17280 > 13:16:24.432767 1035 > yardsql: P 564:639(75) ack 193 win 17280 > 13:16:24.433231 yardsql > 1035: P 193:293(100) ack 639 win 17280 > 13:16:24.632595 1035 > yardsql: . ack 293 win 17280 > 13:16:24.632639 yardsql > 1035: P 293:312(19) ack 639 win 17280 > > The 100 byte syndrome caused a bad fragmentation and delayed the whole > transaction by half a second (mean response time for other exchanges > are about 1 milli-second). > > The solution here seems to force the TCP_NODELAY and ack_delayed=1. > Hi, In short, is it a general problem with the tcpip stack on all platforms ? a specific problem to bsd and bsd like tcpip stack ? Is it a bug ? Why is it working with linux ? Yard modified their application to include a TCP_NODELAY. But they have discovered that after a "dup" the TCP_NODELAY flag was lost. Is it the normal behavior for "dup" ? After the modification by Yard of their source code. It's partly working sometimes the system is very fast (like with delayed_ack=0) and sometimes it becomes extremely slow (like with delay_ack=1). I've been able to reproduce the same phemenon by manually toggling delay_ack why the application was running. Do you have any suggestion ? Thanks for your help -- Didier Derny didier@omnix.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message