Date: Mon, 17 Aug 1998 20:03:09 +0200 (CEST) From: Remy NONNENMACHER <remy@synx.com> To: didier@omnix.net Cc: dg@root.com, hackers@FreeBSD.ORG, support@yard.de Subject: Re: Yard/FreeBSD Problem (fwd) Message-ID: <199808171803.TAA24662@bsd.synx.com> In-Reply-To: <Pine.BSF.3.96.980817163418.4938A-100000@omnix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17 Aug, Didier Derny wrote: > On Mon, 17 Aug 1998, David Greenman wrote: > >> For the server, "s" above appears to be the unconnected (listen) socket. >> The TCP_NODELAY option is not propagated across to accept()ed sockets, so >> you must do the setsockopt on those, not on the listen socket. >> >> -DG >> >> David Greenman >> Co-founder/Principal Architect, The FreeBSD Project >> > > They have made the modification on their program to do the setsockopt > on the connect socket but without any success; > > Is there any possibily to track this socketoption to understand > why it diseappear ? > > When I force the nodelay in the kernel everything works fine > 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. In january, during the 100 byte thread, Luigi Rizzo said: "FreeBSD isn't alone in this by any means and you don't run into it that often, but when you do it is a real pain." He was right ;). RN. 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?199808171803.TAA24662>