> From rmk@rmkhome.rmkhome.com Sat Dec 21 12:02:18 1996
>
> It appears to me that the com drivers in NetBSD/Sun3 1.2 and in
> SunOS 3.5 (which used clists rather than ring buffers) have a
> performance edge over SunOS 4.x or 5.x.
> 
> >Based upon what??
> 
> Based on the woes of many people who have written drivers for SVR4
> and didn't get the performance that they expected.
>

Once again. Based on what. I would expect technical details not
an appearance factor.

I've written the serial drivers for Aurora Technologies serial boards.
I was able to sustain 115.2 over several serial ports on a SS1. I wouldn't
call that a performance problem.

I worked on the spif serial drivers for Sun. I fixed so many bugs
it wasn't funny. But, in the end I get 115.2 over several serial ports.
Once again, I wouldn't call that a performance problem.

I fixed serial bugs on the Hal workstation.

And now, I fix serial problems for SGI in the network group. And they
use STREAMS on their serial ports.

> >Agreed.. Though there are things I like about it. But hey, I enjoy
> >using a Newton and a PC. Everything has faults..
> 
> In my last job I was shouldered with the burden of keeping ~600
> software engineers happily hacking on Solaris 2.3-2.5.  I've seen
> numerous zs3 ring buffer overflows that would lock up the display
> for as long as 30 minutes.  These machines were typically doing
> software builds, running dbx, and the usual assortment of desktop
> apps.  They weren't even using the serial ports.  In the integration
> labs, where Air Traffic Control systems were debugged, heavy use of
> the serial ports for flight strip printers, etc, the impact of ring
> buffer overflows could be seen as being devastating to the landing
> of aircraft.
> 

ring buffer overflows are DRASTICALLY different than silo overflows.
The ring buffer overflows means the serial port is keeping up and it
fill up the buffer for handing off to the upstream layers. upstream
or even the application is having a problem pulling the data off the
port.

silo overflows mean the chip is not able to keep up with the incoming
data. this is a problem with the driver or handshaking..

> The STREAMS based Lachman TCP/IP is inferior to the old SunOS 4.x
> TCP/IP. (the *!#&$^ LANCE chips don't help, either.)
> 
> There are three things that I like about NetBSD.  It's BSD, it has
> been remarkably stable for me, and it runs on a lot of platforms.
> 
> I hope it stays that way.
> -- 


Once again, based on what?? Oh, and by the way, Sun's STREAMS is not
based on Lachman but Mentat..

-brad w.