From owner-freebsd-net  Fri Aug  4 10:18:24 2000
Delivered-To: freebsd-net@freebsd.org
Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7])
	by hub.freebsd.org (Postfix) with ESMTP id 3BB6F37BA5E
	for <freebsd-net@freebsd.org>; Fri,  4 Aug 2000 10:18:21 -0700 (PDT)
	(envelope-from archie@whistle.com)
Received: (from archie@localhost)
	by bubba.whistle.com (8.9.3/8.9.3) id KAA09439
	for freebsd-net@freebsd.org; Fri, 4 Aug 2000 10:18:20 -0700 (PDT)
	(envelope-from archie)
From: Archie Cobbs <archie@whistle.com>
Message-Id: <200008041718.KAA09439@bubba.whistle.com>
Subject: Re: cvs commit: src/sys/netinet tcp_output.c
In-Reply-To: <200008032323.QAA56279@freefall.freebsd.org> from Archie Cobbs at
 "Aug 3, 2000 04:23:37 pm"
To: freebsd-net@freebsd.org
Date: Fri, 4 Aug 2000 10:18:20 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL68 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Archie Cobbs writes:
>   Modified files:
>     sys/netinet          tcp_output.c 
>   Log:
>   Improve performance in the case where ip_output() returns an error.
>   When this happens, we know for sure that the packet data was not
>   received by the peer. Therefore, back out any advancing of the
>   transmit sequence number so that we send the same data the next
>   time we transmit a packet, avoiding a guaranteed missed packet and
>   its resulting TCP transmit slowdown.
>   
>   In most systems ip_output() probably never returns an error, and
>   so this problem is never seen. However, it is more likely to occur
>   with device drivers having short output queues (causing ENOBUFS to
>   be returned when they are full), not to mention low memory situations.
>   
>   Moreover, because of this problem writers of slow devices were
>   required to make an unfortunate choice between (a) having a relatively
>   short output queue (with low latency but low TCP bandwidth because
>   of this problem) or (b) a long output queue (with high latency and
>   high TCP bandwidth). In my particular application (ISDN) it took
>   an output queue equal to ~5 seconds of transmission to avoid ENOBUFS.
>   A more reasonable output queue of 0.5 seconds resulted in only about
>   50% TCP throughput. With this patch full throughput was restored in
>   the latter case.

I wonder if this has anything to do with why the default
interface max transmit queue is IFQ_MAXLEN == 50. Seems
like a rather high number to me. I wonder how they came
up with this number.

Note that if_ppp.c uses this value.. seems kindof
inappropriate for a (potentially) slow PPP link.

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message