Skip site navigation (1)Skip section navigation (2)
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>