From nowicki@Sun.COM  Thu Nov 17 11:40:43 1988
Posted-Date: Thu, 17 Nov 88 11:41:59 PST
Received-Date: Thu, 17 Nov 88 11:40:43 PST
Received: from SUN.COM by venera.isi.edu (5.54/5.51)
	id AA24438; Thu, 17 Nov 88 11:40:43 PST
Received: from snail.Sun.COM by Sun.COM (4.0/SMI-4.0)
	id AA23726; Thu, 17 Nov 88 11:37:37 PST
Received: from sparky.sun.com by snail.Sun.COM (4.0/SMI-4.0)
	id AA15348; Thu, 17 Nov 88 11:40:28 PST
Received: from rose.sun.com by sparky.sun.com (4.1/SMI-4.1)
	id AA04667; Thu, 17 Nov 88 11:41:59 PST
Date: Thu, 17 Nov 88 11:41:59 PST
From: nowicki@Sun.COM (Bill Nowicki)
Message-Id: <8811171941.AA04667@sparky.sun.com>
To: braden@venera.isi.edu
Subject: Re:  Streams as a Principle
Cc: end2end-interest@venera.isi.edu
Status: R

	This suspicion has been fueled by the sad example of the SunOS
	4.0 version of NIT, that uses streams and suffers badly in
	performance as a result.

That is a non-sequitor.  I would be very interested in the details of
your measurements and the actualy numbers you obtained.

There indeed may be some amount of CPU penalty for improvements in
flexibility and administration.  In the commercial world most customers
are willing to make that trade-off, especially when we have 20 MIPS
personal workstations.  In the case of 4.0 NIT, there was no
performance work done on it since we thought reliability and robustness
were more important.  I would suspect that the overhead you are seeing
is due to the fact that the 4.0 Ethernet driver is written using the
"mbuf" buffer allocation package.  Probably if you ran our new Ethernet
driver that uses the STREAMS (mblk) buffer package, you will see the
reverse (socket-based protocol implementations would be slower than
native streams).  I think most members of the task force agree that the
buffer allocation package makes a much larger difference in performance
than how you implement the protocol switch.

	-- WIN