From owner-freebsd-hackers Mon Jul 1 13:12:12 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA04103 for hackers-outgoing; Mon, 1 Jul 1996 13:12:12 -0700 (PDT) Received: from casparc.ppp.net (casparc.ppp.net [194.64.12.35]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id NAA04074 for ; Mon, 1 Jul 1996 13:12:08 -0700 (PDT) Received: from schubert.promo.de by casparc.ppp.net with smtp (Smail3.1.28.1 #1) id m0uapK3-000I0NC; Mon, 1 Jul 96 22:11 MET DST Received: from quick.promo.de (quick.Promo.DE [194.45.188.67]) by schubert.promo.de (8.6.12/8.6.12) with SMTP id AAA00348 for ; Tue, 2 Jul 1996 00:12:33 +0200 Message-ID: Date: 1 Jul 1996 22:10:41 +0200 From: "Stefan Bethke" Subject: TCP time-outs on PPP line To: "FreeBSD Hackers" X-Mailer: Mail*Link SMTP-QM 3.0.2 Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; Name="Message Body" Content-Transfer-Encoding: quoted-printable Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, we are connected through an analog leased line with two USR Courier, = using 2.1.0R and pppd. Since upgrading from Linux we experience some TCP "connection timed out" = failures. It seems that at those moments someone is downloading from our = HTTP or FTP server (looking at the modem leds and = ftpwho/xferlog/http-log). Trying to ping the terminal server of our ISP doesn't give a response; = after 5 or so pings, ping says "No buffer space available". My understanding is that the already established TCP connection quickly = fills the output buffer and saturates the line; at this point, a packet = inserted into the queue will be sent after (worst case) mtu / bandwith * = queue length (ifq_maxlen) =3D 1500 / 2880 * 50 =3D 27 seconds. (Or, = taking fastq into account, 54 secs). What's the solution? Possibilities are - reduce ifq_maxlen, so ENOBUF will be returned earlier, so TCP will (hopefully) send slower earlier; - reduce the mtu, so a full queue run will be faster, thereby allowing a = new packet to be sent faster; - devise a mechanism to promote those connections we want to precede our external users' connections to the fastq; possibly by promoting all packets smaller than xxx bytes to fastq; - upgrade to a 2 Mbit line :-) I didn't test any of these yet, because I rather like to have a slow but = working line... Any comments will be greatly appreciated. Stefan Bethke -- Promo Datentechnik | Tel. 040/431360-0 + Systemberatung GmbH | Fax. 040/431360-60 Waterloohain 6-8 | e-mail: stefan@Promo.DE D-22769 Hamburg | http://www.Promo.DE/