Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Jul 1995 19:21:02 GMT
From:      Pete Carah <pete@puffin.pelican.com>
To:        bde@zeta.org.au
Cc:        current@freebsd.org
Subject:   Re: kern/579: sio: RS_IBUFSIZE 256 too small
Message-ID:  <199507021921.TAA26200@puffin.pelican.com>
In-Reply-To: <199507021519.BAA16708@godzilla.zeta.org.au>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507021921.TAA26200>