SUN-Spots Digest, v3n13

[Scott Alexander]

SUN-SPOTS DIGEST            Wednesday, 4 Dec 1985          Volume 3 : Issue 13

Today's Topics:
		  Mixing Sun-2's and Sun-3's (new question)
			Re: Sun-2's versus Sun-3's (2)
			     Sun-3 floating point
				  Sun-3 VDMA
			   MIDI interface for Suns
	 Anyone have a ttywindow menu filter program? (1.x or 2.x ?)
------------------------------------------------------------------------
Date:  3 Dec 1985 1658-PST (Tuesday)
From: trwrb!trwspp!spp1!ritter at ucbvax.berkeley.edu (Phillip A. Ritter)
Subject: Mixing Sun-2's and Sun-3's (new question)

I understand that Sun-2's need Sun-2's as ND servers, and that Sun-3's need
Sun-3's as ND servers (for now).  I even understand why!  I also understand
that Sun-2's and Sun-3's may share NFS filesystems.

Question:  Can Sun-2's and Sun-3's share a common /usr file system?  In
particular, we currently have two file servers (both 2/130's with 2 eagles),
with seven Sun-2's (mostly 2/50's) as clients on each server.  All of the
clients mount /usr from the same the file server (so that we don't have to
dedicate 150Mb of disk twice).  We are getting some 3/75's and Sun-3
upgrades for the file servers.  What I would like to do is upgrade one of
the file servers, put /usr and the Sun-3 clients on it, and move all of the
Sun-2 clients to the second file server (upgrading it when the magical Feb.
release comes out).  Will there be any problems with Sun-2's and Sun-3's
sharing a common /usr?  (In particular, with anthing that might contain
68010/68020 dependencies [in /usr/etc, maybe]).

Phil Ritter
TRW System Development Division
UUCP: {decvax,ucbvax,ihnp4}!trwrb!trwspp!spp1!ritter
ARPA: trwrb!trwspp!spp1!ritter at ucbvax.ARPA (or is that .EDU now?)

-----------------------------

Date: Sun, 1 Dec 85 19:29:25 est
From: Sid Stuart <seismo!philabs!linus!sid at ucbvax.berkeley.edu>
Subject: Re: Sun-2's versus Sun-3's
Organization: The Mitre Corporation, Bedford MA

I disagree with William LeFarber's reasoning about the problems with the Sun
2's and 3's not sharing nd services.  The basis of his conjecture was that
the server and the diskless nodes boot off of the same kernel. On my Suns,
the server boots off of /vmunix, the diskless nodes off of /pub/vmunix,
these are different kernals and have been configured differently. I tried to
write him a letter, but his computer wasn't in my uucp map.

I think the conflict between the Sun 2 and 3 is strictly in the nd services.
The first problem is that Sun has not set up the capability to boot
different kernels from /pub. The second is the 2K versus 8K page sizes for
the swap space, thus the nd server would need to work for both and is is not
currently set up to do so. The third is that the systems are running
different releases of the OS and will do so until the promised release in
January, or was that Feb.? Of course this is all conjecture because my Suns
are still in the mail. I will know for sure, hopefully, by the end of Dec.

As far as I know, the NFS services should be compatible between 2's and 3's
except for the already mentioned difficulty with the 3com board in some Sun
2 products. If this is not so I would like to hear about it. If it is so
then I am not sure what the fuss is about. The NFS takes up most of the CPU
time on my servers, not the nd. If I add a 3 that does NFS services for my
2's then I should see a big win. I don't understand why anyone would buy a
Sun 2 at this point so none of us should need additional nd services over
that of what we have. It might be nice to run a 3/75 off an existing 2
server, but from what the benchmark paper says, a 2 system is hard pressed
to serve more than 3 or 4 3 systems, so it seems like a waste of money.

Of course I have a bent personality. I hear from my salesman that the
delivery dates on 2 systems are 3 or 4 months from time of order, while 3
systems are still 45 to 60 days. WHY would anyone want a computer that runs
3 times as slow for only 30% less in cost? For the added performance, one
should certainly scrape up the extra money.  Especially for 2/50's, as they
cannot be upgraded.


					sid at linus

-----------------------------

Date:     Wed,  4 Dec 85 13:21:56 CST
From: William LeFebvre <phil at rice.edu>
Subject:  Re: Sun-2's versus Sun-3's

>Sid Stuart:
>	I disagree with William LeFarber's reasoning about the...

That's "LeFebvre".

> The basis of his conjecture was that the server and the diskless nodes
> boot off of the same kernel. On my Suns, the server boots off of
> /vmunix, the diskless nodes off of /pub/vmunix, these are different
> kernals and have been configured differently.

This is correct, and I apologize for the misdirection.  That point
doesn't change my argument, however.  My conjecture is based (in part)
on the statement that different clients running off the same server
must run the same kernel.  I took this one extra step and assumed that
the server must also be running the same kernel.  Note that this
"restriction" is not absolute (as I mentioned in my last letter).  One
can get around it.  I would say that it is more of an assumption than
an iron-clad rule.

> I think the conflict between the Sun 2 and 3 is strictly in the nd
> services. The first problem is that Sun has not set up the capability
> to boot different kernels from /pub. 

The second statement has nothing to do with the first.  ND doesn't care
much about the data it is sending, only the stuff that goes around it and
(perhaps) how big it is.

> The second is the 2K versus 8K page sizes for the swap space, thus the
> nd server would need to work for both and is is not currently set up to
> do so.

This is the best argument I've heard yet!  It could very well be the case.

> The third is that the systems are running different releases of the OS
> and will do so until the promised release in January, or was that Feb.?

Why should that make a difference?  Unless there are different versions
of the ND and NFS specs (or unless there are implicit assumptions about
how those protocols operate -- such as moving 8K swap packets instead
of 2K).  I can always make sure that my clients have completely
distinct disk partitions on the servers, so different versions of
user-level software should not be a problem.  Or am I overlooking
something?

(One advantage to having the moderator as an officemate is that I can
reply to messages in the same digest!)

			William LeFebvre

-----------------------------

Date: Mon, 2 Dec 85 15:47:01 pst
From: gould9!joel at nosc.ARPA (Joel West @ CACI)
Organization: CACI, Inc. -- La Jolla (home of SIMSCRIPT II.5)
Subject: Sun-3 floating point
Keywords: binary compatibility

This is probably a trivial question -- I don't currently have a 
Sun-3, but may evenutally port software to one.

I understand two Sun-3 configurations are distinct in their 
approach to floating point arithmetic:
	* 68020 + 68881
	* 68020 + Weitek (?) FP board
The second is somewhat faster and is expected to be more popular, I'm told.

Are executables for these two variants binary compatible, i.e., does 
the compiler have to know what machine it is targetting?  If so, I 
assume this means the FP board is emulating the 68881 instruction set, 
or some such.

The machine-language equivalent of the following VAX sequence for one
or both configurations would be appreciated.

	/*	A = B * C + D  */
		movd	B,r0
		muld2	C,r0
		addd2	D,r0
		movd	r0,A

-----------------------------

From: tektronix!watmath!wateng!eclam at ucbvax.berkeley.edu
Date: Sun, 1 Dec 85 17:27:10 est
Subject: Sun-3 VDMA
Organization: U. of Waterloo, Ontario

I am interested in SUN-3's VDMA.  I wonder if we could discuss it in 
this news group. 


-- 
        -Edmund C. Lam    (University of Waterloo)
	...decvax!watmath!wateng!eclam
	<eclam%wateng%waterloo.csnet>
	<eclam at eng.waterloo.cdn>

-----------------------------

Date: Fri, 29 Nov 85 19:07:45 EST
From: sean at cadre.dsl.pittsburgh.edu (Sean McLinden)
Subject: MIDI interface for Suns


Does anyone have any information on MIDI compatible interfaces for the
Sun-2 or Sun-3?

Sean McLinden
Decision Systems Laboratory
University of Pittsburgh

-----------------------------

Date: 02 Dec 85 17:02:31 EST (Mon)
Subject: Anyone have a ttywindow menu filter program? (1.x or 2.x ?)
From: ted%bragg1 at braggfs

Hello folks,

It recently came to me that it would be very nice if there were an easy
way to add a menu interface to existing tty oriented utilities.  What I had
in mind was something (a tool) that creates a tty emulation subwindow 
and is totally passive while the user interacts as usual with the utility.  
When he hits the menu button on the mouse, however, he should get a menu set 
up by an rc file which performs a "stuff" of the appropriate characters to 
accomplish whatever function he had selected.  The menu messages and the 
characters to "stuff" should be user definable.  The menu entries would do 
exactly what the "stuff" option does, except that instead of entering the 
last "grabbed" text, they should enter whatever the rc file had defined for 
them.  The original "stuff" option should, of course, still be available.

The example that first springs to mind of where this would be a real help is
emacs, where the modelessness makes it a natural (you could define entries
for all sorts of nice things), but it should be more generally useful too.
The idea seems so obvious, that I imagine it must have been done before.
Does anyone have any pointers?

				Thanks,
				Ted Nolan
				ted at braggfs

-----------------------------

End of SUN-Spots Digest
***********************