Bill Studenmund writes:
> On Tue, 11 Nov 1997, David Jones wrote:
> 
> > Brad Salai wrote:
> > | At 11:43 AM -0800 11/11/97, "Erik E. Fair" (Time Keeper) wrote:
> > | >The IPX and SS2 are the fastest stock sun4c systems (40 MHz). If it's still
> > | >unusable at 38400, we still have a ways to go.
> > | >
> > | >	Erik <fair@clock.org>
> > | 
> > | This is bound to sound like a whine, but is not, just a little frustration.
> > | 
> > | I switched from a 16MHz MacII 68020 which had no trouble with 38400 or
> > | higher, to a Sparc, to get more speed.
> > 
> > Same here:
> > 
> > Amiga 3000 (16 MHz 68030, custom UART, no FIFO, no hardware flow control)
> > - Does 38400 no problem.
> > 
> > Sparc IPC (25 MHz sun4c, zs8530, supposedly 16-character FIFO)
> > - Drops characters at 19200.
> > 
> > The problem is the 8530: it is a very slow part; it must be accessed at
> > most once every 2us.
> 
> The 8530 is NOT the problem. Mac68k computers use the same part, and
> perform quite well. We've supported 38400 w/o hw flow control, and I've
> been able to run at 57600 w/ flow control.
> 
> 2us == 500 kHz. Chip speed isn't a problem here. A royal pain if the
> delay's not in hardware, but not this problem.
> 
> The problem is that the chip is not getting responded to fast enough.
> Something in the system is keeping interrupts locked out for quite a
> while. From what I can see of /sys/arch/sparc/include/psl.h, only
> splaudio, splstatclock, and splhigh would be higher than the zs hardware
> interrupt.
> 
> So something's blocking interrupts for too long.
> 
> Take care,
> 
> Bill


the "something" is the scheduler.  context switches on the sparc
are sllllloooowwww under netbsd, which wouldn't matter except that
all interrupts are held while that's going on (see kern_sched.c:tsleep()).

if you want to see the overruns really fly, run about 10 copies of
	perl -e 'while (1) { select(undef, undef, undef, 0.1) }'
on an SS1 (more on a faster machine) and then try to do some serial i/o.

I've proposed a fix which pk has reposted for discussion on tech-kern.

-Chuck