From owner-freebsd-questions Mon Jul 1 05:00:52 1996 Return-Path: owner-questions Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA22564 for questions-outgoing; Mon, 1 Jul 1996 05:00:52 -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 FAA22556 for ; Mon, 1 Jul 1996 05:00:50 -0700 (PDT) Received: from schubert.promo.de by casparc.ppp.net with smtp (Smail3.1.28.1 #1) id m0uagfM-000Hz6C; Mon, 1 Jul 96 12:57 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 MAA08936 for ; Mon, 1 Jul 1996 12:55:09 +0200 Message-ID: Date: 1 Jul 1996 12:56:12 +0200 From: "Stefan Bethke" Subject: TCP time-outs on PPP line To: "FreeBSD Questions" 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-questions@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 provider 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/