From owner-freebsd-current Fri Mar 10 08:58:20 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id IAA18069 for current-outgoing; Fri, 10 Mar 1995 08:58:20 -0800 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id IAA18063 for ; Fri, 10 Mar 1995 08:58:17 -0800 Received: by pelican.com (Smail3.1.28.1 #5) id m0rn80V-000K3WC; Fri, 10 Mar 95 08:57 WET Message-Id: From: pete@pelican.com (Pete Carah) Subject: Re: bad outgoing serial coms To: bde@zeta.org.au (Bruce Evans) Date: Fri, 10 Mar 1995 08:57:43 -0800 (PST) Cc: current@FreeBSD.org In-Reply-To: <199503101115.VAA30652@godzilla.zeta.org.au> from "Bruce Evans" at Mar 10, 95 09:15:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1743 Sender: current-owner@FreeBSD.org Precedence: bulk Bruce Evans writes: > >Make TTYHOG big - one friend of mine needs 10240 and another 8192. > >It could need to be as big as Taylor's i-protocol window which is > >16384 (if your problem is with uucp). > RTS flow control is supposed to work now, so the big buffers should > be unnecessary (but advisable for speed) if whatever you are connecting > to supports CTS flow control. That is not (all of) the problem; my friend here who gets this message all the time uses rts/cts and at least it works going out. As far as I know his modems support rts/cts both ways and are config'd right. I'll try to look further at his configuration. He only sees this message with uucp, though, and also only sees it when there are lots of file turnarounds in 'i' protocol (like with the mail for freebsd-* with short messages). My modems here are on a 1.1.5 system and it isn't convenient to put either one on the 2.x system yet; I know that both directions of flow control work on the 1.1.5.... > >If you are using another protocol, TTYHOG may need to be as big > >as the TCP window plus the overhead; this probably defaults to 4096 or > >8192. > > SLIP and PPP don't use clists for input so they don't depend on TTYHOG. The cited message comes from a place that involves the "raw" clist queue. There is only one place in the driver that increments the counter involved... -------------------------------------------------- com->delta_error_counts[CE_TTY_BUF_OVERFLOW] += b_to_q((char *)buf, incc, &tp->t_rawq); --------------------------------------------------- I don't know why it might come in slip/ppp if they don't use clists; are you *sure* they don't use the raw clist queue? -- Pete