Date: Wed, 19 Aug 1998 09:18:53 +0200 (CEST) From: Didier Derny <didier@omnix.net> To: Remy NONNENMACHER <remy@synx.com> Cc: dg@root.com, hackers@FreeBSD.ORG, support@yard.de Subject: Re: Yard/FreeBSD Problem (fwd) Message-ID: <Pine.BSF.3.96.980819091204.25143A-100000@omnix.net> In-Reply-To: <199808171803.TAA24662@bsd.synx.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980819091204.25143A-100000>