Path: utzoo!attcan!uunet!cs.utexas.edu!csd4.milw.wisc.edu!bionet!agate!ucbvax!IU.AI.SRI.COM!KASHTAN
From: KASHTAN@IU.AI.SRI.COM (David L. Kashtan)
Newsgroups: comp.protocols.tcp-ip
Subject: (none)
Message-ID: <614756942.880000.KASHTAN@IU.AI.SRI.COM>
Date: 25 Jun 89 06:49:02 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 101


As one of the developers of MultiNet I wanted to take this
opportunity to thank you for those positive responses regarding
MultiNet TCP/IP for VAX/VMS.  I also wanted to point out a
couple of inaccuracies and respond to Randy Catoe's messages
about MultiProcessor synchronization and VAX/VMS SpinLocks:

1) With all due respect to Mr. Catoe (and I quote):

  "The WIN/TCP networking kernel differs from its competitors in that we have built
   an SMP implementation that accomplishes multi-processor synchronization on
   a per connection basis. The result is that we incur far less multi-processor
   synchronization overhead than in other approaches. This results in more
   processor resources for other computing."

	If by synchronization overhead you refer to the overhead of
	acquiring/releasing Multiprocessor synchronization locks,
	the choice of fine-grained vs. course-grained locking makes
	no difference whatsoever (although it is possible, if you
	try to minimize the time that locks are held, to incur
	GREATER overhead with the fine-grained locking scheme
	due to  the multiple acquisition/release of spinlocks).

	I think the real debate is over the amount "spinning"
	done by CPU's that are waiting to acquire a spinlock.
	I must say, at the outset, that my initial (and intuitive)
	reaction is that having a spinlock per connection would
	be a big win over having several "strategically" chosen
	global spinlocks.  Luckily, we did NOT press ahead with
	the scheme that Wollongong used before implementing the
	easier "global" spinlock scheme and measuring its
	performance.

	Before talking about performance, I would like to point
	out a side issue that is actually quite significant.
	Both MultiNet and Wollongong's WIN/TCP use the 4.Xbsd
	Berkeley TCP protocol modules.  I feel that in order
	to participate in and derive benefit from 4.Xbsd
	protocol development it is necessary to minimize
	source changes to accomodate VAX/VMS MultiProcessing.
	Although I have not seen Mr. Catoe's sources, I would
	bet that they underwent some pretty serious modification
	to accomodate a spinlock per connection.  The MultiNet
	scheme of a few well chosen global spinlocks required
	NO source changes to the 4.Xbsd TCP protocol modules.

	Now for performance:  We did some performance measurement
	on several MultiProcessor machines with 100-150 active
	network	logins (some were Telnet and some were Rlogin).
	The MultiNet scheme resulted in an average of 2.8% of
	CPU time spent in network spinlock sychronization
	(this compares favorably to the 1.5% CPU time spent
	 in spinlock synchronization due to the VAX/VMS scheduler)!
	So -- in the best of cases, Mr Catoe's scheme might
	buy you an extra couple of percent of CPU.  But also
	note that we got an overall GAIN of 10% by using the
	GNU "C" compiler instead of the UNIX-PCC compiler
	(which is used to compile Wollongong's WIN/TCP).

	It is my understanding that the folks at NRC
	(FUSION TCP/IP) were using per connection spinlocks
	and ripped them out in favor of global spinlocks --
	they got better performance.

	My conclusion -- don't always follow your intuition
	without testing the concepts first.  Fine-grained
	locking is not always as good as one might think
	it would be.  And ALWAYS use the best compiler you
	can find!

2) "MultiNet from SRI comes with full sources..."

	MultiNet from SRI comes with partial sources, the
	sources for several key modules (the interface
	between the networking protocols and the VAX/VMS
	kernel) are not supplied, although the object modules
	ARE provided -- so you can indeed link the network.
	Full sources are supplied for all the network protocol
	modules and all the User-Level clients and servers.


3) There was an excerpt from a letter that I wrote that was obviously
   VERY OLD.  My host hasn't been SRI-IU.ARPA for many years!

	>To recompile any of the user-level code will require the DEC
	>VAX-11 "C" compiler.  It is unlikely that you will need to
	>recompile anything.
	>
	>To recompile the networking kernel will require either a VMS system
	>that also has Eunice (A UNIX system layered on top of VMS) or a VAX
	>running 4.2bsd or 4.3bsd UNIX.  It is VERY unlikely that you will
	>need to recompile the networking kernel.

    ALL the MultiNet code (both the networking kernel and the
    user-level code) is now compiled using the GNU "C" compiler,
    which is provided as part of the MultiNet distribution.  The
    switch from Eunice/UNIX-PCC to GCC got us about 10% better
    performance from the network kernel.


-------