Return to BSD News archive
Newsgroups: comp.unix.bsd.freebsd.misc
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!news.sdsmt.edu!news.mid.net!news.dra.com!netaxs.com!news1.erols.com!howland.erols.net!www.nntp.primenet.com!nntp.primenet.com!uunet!in3.uu.net!news.compuserve.com!ix.netcom.com!netcom.com!gerg
From: gerg@netcom.com (Greg Andrews)
Subject: Re: 2.1.5-RELEASE sio silo overflows?
Message-ID: <gergDxG5ry.FGo@netcom.com>
Organization: Movie marquee: THE FLY GODS MUST BE CRAZY ALIENS
References: <50i54c$mq7@yama.mcc.ac.uk> <50kb48$9ok@helena.mt.net>
Date: Mon, 9 Sep 1996 03:59:58 GMT
Lines: 81
Sender: gerg@netcom23.netcom.com
"Nate Williams" <nate@sneezy.sri.com> writes:
>In article <50i54c$mq7@yama.mcc.ac.uk>, Ian Pallfreeman <ip@mcc.ac.uk> wrote:
>>My home PC has recently joined my ever-growing collection of happy FreeBSD
>>boxes, with Linux banished to the backup tapes. Everything's groovy as I
>>expected, except I'm getting a whole slew of:
>>
>> Sep 3 21:29:55 clover /kernel: sio2: 4 more silo overflows (total 448)
>>
>>when using SLIP (dialing with dip). I'm using a 16550A:
>
>This is a 'known problem' with 2.1.5R. Basically, Bruce modified the
>driver to actually *report* overflows that weren't being reported in
>previous versions of FreeBSD. The solution is to either ignore them
>(I've been doing this), or modify sio.c to set the trigger level from 14
>to 8 in the sources which should remove them at some interrupt cost.
>
>This was talked about a couple weeks ago in the mailing lists, and Bruce
>has no idea why I'm seeing them, since I have *real* 16550A's and my
>SCSI card isn't hogging the bus too long. In any case, I suspect my
>change to sio.c should do the trick, although I haven't rebooted with
>the new kernel to check yet. :)
>
The uart's interrupt trigger is set to *14*??!?
Man, I thought people had figured that one out by now.
On OS architectures that carry a lot of latency responding
to hardware interrupts (like a multi-user, multitasking OS),
a trigger level of 14 is *not* adequate to prevent overflow
errors.
Consider the 8250/16450 uarts. They have the equivalent
trigger level of 15. That is, you have only one character's
worth of time to respond to the interrupt, or it will be
overflowed (overwritten) by the next character. That time
window is:
RS232 speed Max latency on 8250/16450
------------------------------------------
9600 bps 1042 us (1.042 ms)
19200 bps 520 us
38400 bps 260 us
57600 bps 174 us
115200 bps 86.8 us
On a 16550A with the trigger level at 14, you have two
character's worth of time to respond to the interrupt
(as the 15th and 16th characters arrive). So by setting
the trigger level to 14, you double your latency tolerance.
That's nice, but the speeds your customers are using have
*tripled* from 19200 to 57600 bps. Your tolerance is now
348 microseconds before you lose characters from overflows.
That's a damn low tolerance. Too low, in my opinion (though I'm
no device driver guru). By contrast, when the trigger level is
set to 8, so you have 1392 us to respond to the interrupt at 57600
bps. 1.3 ms is more than you need, but the extra headroom can
only help. It gives you 694 microseconds when the customer decides
to set the speed to 115200 bps, and that's definitely a win over
a mere 174 microseconds (trigger level at 14)!
I know that you set the level to 14 to minimize the number of
hardware interrupts you have to handle when data is being received
in a thick, fast stream. That's good, but the benefit of lower
cpu loading doesn't balance the drawback of character packet loss
from overflows.
So I think you should change the default trigger level to 8, or
make the trigger level available to the user to configure and
document the tradeoffs between the 8 and 14 character settings.
The latter would be preferable, IMO.
-Greg
--
::::::::::::::::::: Greg Andrews gerg@netcom.com :::::::::::::::::::
ObGuindon: With the help of hypnosis, Claire Fuller was able
to gain fifteen pounds in the last three weeks.
:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::