Bruce,
could you test this patch and compare the results.
By generating an ACK for every segment with the TH_PSH flag set
I found a significant increase in throughput.
Index: tcp_input.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.122
diff -u -r1.122 tcp_input.c
--- tcp_input.c 2001/01/24 16:25:36 1.122
+++ tcp_input.c 2001/01/25 08:08:36
@@ -966,7 +966,7 @@
m_adj(m, drop_hdrlen); /* delayed header drop */
sbappend(&so->so_rcv, m);
sorwakeup(so);
- if (tcp_delack_enabled) {
+ if ((tcp_delack_enabled) && !(th->th_flags & TH_PSH)){
callout_reset(tp->tt_delack, tcp_delacktime,
tcp_timer_delack, tp);
} else {
jayanth
Bruce Evans ([EMAIL PROTECTED]) wrote:
> On Wed, 24 Jan 2001, Jordan Hubbard wrote:
>
> > > Something just doesn't sit well me. This shouldn't happen in a
> > > 100Mbit LAN. This seems like a plain vanilla network transaction, and
> > > FreeBSD is failing on something, where other OSes in the same
> > > environment don't.
> >
> > You're almost certainly correct that there's a misfeature lurking in
> > there somewhere, I don't think anybody's arguing that particular
> > point, it's just that you're also (sadly) in a much better position to
> > diagnose this than [m]any of your readers since we don't have an
> > active failure scenario to analyze like you do. :(
>
> I diagnosed similar problems in rmt(8) a few (?) months ago. Try:
>
> tar cf localhost:/tmp/foo /boot/kernel
>
> With the FreeBSD defaults, this crawls at almost precisely 100K/sec
> due to its protocol waiting for an ack after every 10K block and acks
> being delayed by 100 msec.
>
> Bruce
>
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-net" in the body of the message
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
