From owner-freebsd-current Sun Jul 2 12:21:11 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA07481 for current-outgoing; Sun, 2 Jul 1995 12:21:11 -0700 Received: from pelican.com (pelican.com [134.24.4.62]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA07474 for ; Sun, 2 Jul 1995 12:21:07 -0700 Received: from puffin.pelican.com by pelican.com with smtp (Smail3.1.28.1 #5) id m0sSUZi-000K0qC; Sun, 2 Jul 95 12:21 WET DST Received: (from pete@localhost) by puffin.pelican.com (8.6.11/8.6.9) id TAA26200; Sun, 2 Jul 1995 19:21:02 GMT Date: Sun, 2 Jul 1995 19:21:02 GMT From: Pete Carah Message-Id: <199507021921.TAA26200@puffin.pelican.com> To: bde@zeta.org.au Subject: Re: kern/579: sio: RS_IBUFSIZE 256 too small In-Reply-To: <199507021519.BAA16708@godzilla.zeta.org.au> Cc: current@freebsd.org Sender: current-owner@freebsd.org Precedence: bulk In article <199507021519.BAA16708@godzilla.zeta.org.au> you write: >>>Synopsis: sio: RS_IBUFSIZE at 256 bytes serial lines loose data (PPP) >> A 486-40 with 6 16550 ports and 4 ethernets (3 active) >> A 386-16 with 1 16550 ports and 1 ethernet (just a PPP router) >>>Description: >> Both these machines report "interrupt-level buffer overflow":s >> very frequently on a leased line running at 38400, badly dropping >> IP performance. >This is because you don't use crtscts and something or other delays >softclock() by more than (RB_IBUFSIZE - ceil(38400/10/100.0) = 217 >character times, i.e., for more than 5.5 clock interrupts. Hardware >interrupts and all other software interrupts have priority over >softclock(), so any solid block of hardware or net interrupts would do >this. I would be surprised if ethernet interrupts on the 386/16 didn't >do it. WRONG. It shows up on raw ports where I KNOW that crtscts is in use *AND WORKS* in cooked mode *in the same connection*. The *ONLY* cure for this (so far) is to increase ttyhog to whatever your protocol's window size is; this works fine, and since no chars are ever dropped in this situation once ttyhog is icreased, I suspect that interrupt latency is *not* a problem. I know we've been over this a lot in the past; something *has* to be wrong in the driver, but I don't know what it is; apparently rts isn't being dropped when it should be, but only in raw mode. ............ >> On 386-16 I also saw several spontaneous reboots when loading the >> PPP link. > >Another problem. I saw a spontaneous reboot today when I did something >silly involving pppd and tcpdump. The system normally just panics when >tcpdump is killed after pppd is killed. Is this the old route delete bug? Must be independent of ttyhog and such. I have seen a few bpf commits recently to deal with tcpdump on down interfaces. Don't know if they fix anything since I don't use bpf particularly. >> I changed RS_IBUFSIZE from 256 to 4096, and the problem disappeared. >> It might be that a smaller amount would be sufficient (I don't mind >> 8k memory waste per line in this case). But it is apparent that >> 256 bytes seems not sufficient for slow or loaded machines. ..... >>sio.c: >>< #define RS_IBUFSIZE 256 >>-- >>> #define RS_IBUFSIZE 4096 > >This breaks crtscts unless you make TTYHOG 16 times as large to match. >The watermark RB_I_HIGH_WATER = (TTYHOG - 2 * RB_IBUFSIZE) must be >significantly larger than 0. TTYHOG must to be larger than 2 * RB_IBUFSIZE >even without crtscts. I make this problem go away just by increasing ttyhog without touching ibufsize; this is why I don't think there is any interrupt latency problem; ttyhog "fixes" process-dispatch latencies instead. -- Pete