Sun-Spots-Request@RICE.EDU (Scott Alexander) (12/04/85)
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@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@ucbvax.ARPA (or is that .EDU now?) ----------------------------- Date: Sun, 1 Dec 85 19:29:25 est From: Sid Stuart <seismo!philabs!linus!sid@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@linus ----------------------------- Date: Wed, 4 Dec 85 13:21:56 CST From: William LeFebvre <phil@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@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@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@eng.waterloo.cdn> ----------------------------- Date: Fri, 29 Nov 85 19:07:45 EST From: sean@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@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@braggfs ----------------------------- End of SUN-Spots Digest ***********************