Subject: Re: High serial port (output) speeds
To: None <port-sparc@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: port-sparc
Date: 10/23/1999 16:53:39
>> Handling input at 57600 would be nontrivial even if the hardware had
>> no problems achieving the baud rate. :-/

> I've got my Mac IIci (68030/25) running as a NAT box at 115,200 bps
> with an ISDN TA.  The machine is essentially unresponsive during
> transfer bursts, but it gives ~7,100 bytes/sec without dropping a
> single packet.

Hm!  Perhaps I should actually *try* a NetBSD/sparc box at high
baudrates.  I've certainly heard enough horror stories about data loss
during high speed input, but have never done careful tests.

> Actually, I was pretty surprised to hear the sparc port cuts off at
> 38k4.  Is this an interrupt priority issue?

Well, even without my patch, it should do 51200 and 76800.  I don't
know how well it would handle input at that sort of rate, though; the
problem with high speeds has always been basically input-only, and is
not baud rate per se but rather aggregate data rate.  Lone characters
at 76800 baud, at the rate of one character every 25 milliseconds or
so, that's no problem despite the high baud rate. :-)

My understanding is that it's not so much an interrupt *priority* issue
as an interrupt *latency* issue, coupled with an interrupt rate issue.

Of course, at really high data rates, the CPU will enter the interrupt
handler once and scarf up all available input without leaving it.  Data
rates high enough to provoke this behavior might behave even *better*
than data rates like 38400 or 76800 - but if you're doing something
like PPP you want to make sure the ring buffer between the hard
interrupt and the soft interrupt is large enough to take an entire
packet.

You also might want to have zstty_rxint loop a few times watching
ZSRR0_RX_READY (possibly only when the baud rate is very high), in the
hope that another char will come in soon enough to be worth not
returning from the interrupt.  (It already loops until the chip is
drained, but the Z8530 has borderline-nonexistent hardware buffering,
at least in my experience playing with the NeXT "black" hardware.)

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B