[mod.computers.sun] SUN-Spots Digest, v3n12

Sun-Spots-Request@RICE.EDU (Scott Alexander) (11/30/85)

SUN-SPOTS DIGEST            Friday, 29 Nov 1985            Volume 3 : Issue 12

Today's Topics:
				administrivia
			drivel on undigestified lists.
		Sun 3/180 file servers, mixing Sun 2's and 3's
			   mixing sun2's and sun3's
			      Voice recognition
			     syncronous tty ports
	      Interleaf, Sun 2.0, Sky floating point accelerator
		  EAN electronic mailing on Sun workstations
			 file system panics under 2.0
				Sun vs. Apollo
		    problems with serial ports on zs board
       Survey -  Window Managers/User Interfaces and Dist. File Systems
------------------------------------------------------------------------

Date: Fri, 29 Nov 85 16:59:21 CST
From: Scott Alexander <sun-spots-request@rice.edu>
Subject: administrivia

Sorry for the half week delay.  Our network got very confused around the
beginning of the week.

It seems to be time for another reminder of the purpose of the two
addresses: sun-spots@rice and sun-spots-request@rice.  The former is for
submissions.  If you send something to it, you should be prepared for it to
show up in the digest.  The latter is for administrative messages to the
moderator.  Send things here on which you want me to act, but which you do
not want to see in the digest.

Scott

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

Date: Thu, 21 Nov 85 20:23:18 EST
From: Mark Weiser <mark@mimsy.umd.edu>
Subject: drivel on undigestified lists.

People who complained about drivel on undisgestified lists don't know
recognize that lack of digest does not mean lack of supervision.  All
mail can pass by a person before being resent, but this means
only a 24 or so delay, not weeks or months.  Laser-lovers is an example
of a successful supervised but undigestified list.
	-mark

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

Date: Tue, 19 Nov 85 23:31:03 EST
From: Dan Blumenfeld <DAN@MIT-MC.ARPA>
Subject: Sun 3/180 file servers, mixing Sun 2's and 3's

According to our local sales person, the Sun 3/180 file server will
not enter production until the middle of January 1986.  The waiting list
for them is rather long, and it's probably not the best idea getting
serial number < 100.  A good alternative is the 3/160-M (or without
monitor) which is deskside rather than rack-mountable.  Rumor has it 
that machines configured in multiples of 4Mb RAM will be the first
to ship.  Lead times are currently running between 45-60 days for 
3/160's.

Concerning the mix of 2 and 3 series of Suns, the people that I've
spoken to at Sun relay similar info:  diskless 2's can't be served by
3's, etc., though supposedly disked 2's (which, of course, have been
booted locally) will pass files OK and can handle NFS.  Maybe yes,
maybe no... we've ordered some 3 series Suns and have a 2/120, so
we'll know soon enough!  Then again, considering the lead times for 
the Sun 3 equipment, they may have the problem fixed by the time we
receive the machines.

Dan Blumenfeld
University of Pennsylvania
[blumen@wharton, dan@mc]

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

Date: Sun, 24 Nov 85 12:10:40 pst
From: brent%pride@BERKELEY.EDU (Brent Welch)
Subject: mixing sun2's and sun3's

I have another point to make about mixing sun2's and sun3's.
There is a problem with the network protocol used to communicate
between the servers and the clients.  They use UDP for packet
delivery. UDP uses IP, and in particular, IP fragments UDP packets
that are too large for the ethernet.  NFS and ND do block writes
of 4K which get fragmented into 1K fragments by IP.  Well, a
Sun3 can send the four fragments much faster than a Sun2 can
receive them.  The result is that fragments get dropped by the
Sun2 receiver.  Because IP is not reliable, the loss of just
one fragment causes the whole packet to be tossed...
This makes it nearly impossible to send fragmented packets
from Sun3's to Sun2's.  I've heard of a patch that
limits the sizes of writes to avoid this problem.  I think it's
a new option to the mount command.  In the meantime, sun is
probably working on a better fix.
	brent

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

Date: Fri, 22 Nov 85 13:56:16 cst
From: tj@texsun.UUCP (Cal Thixton   Sun Microsystems  Dallas Office)
Telephone: (214) 823-2084   Office Phone: (214) 788-1951
Purpose-In-Life: To Spread the Gospel of UN*X to the heathens
Subject: Voice recognition

Does anyone know of work on Suns with voice recognition?
        thanks
                cal thixton

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

Date: Tue, 19 Nov 85 20:28:24 EST
From: rtm@harvard.HARVARD.EDU (Robert Morris)
Subject: syncronous tty ports

Does anyone know how to use the SUN2 cpu tty ports syncronously?
Is there any way to run HDLC on them?

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

Date: Tue, 19 Nov 85 22:55:48 cst
From: King Ables <ables%dopey%mcc-pp@mcc.arpa>
Subject: Interleaf, Sun 2.0, Sky floating point accelerator

Does anybody run this combination... successfully?  On our machines,
Interleaf seems to catch an interrupt from the Sky board (if I move
/dev/sky to something else and reboot so the microcode isn't loaded,
Interleaf works just great).  Interleaf doesn't have much interest
in figuring out what the problem is since they don't officially support
2.0 yet.  Our solution for now is not to run Interleaf and floating
point applications (that need the sky board) on the same machine w/o
rebooting in between (yuk).  Anybody seen/dealt with this problem?

-King
ARPA: ables@mcc
UUCP: {ihnp4,seismo,ctvax}!ut-sally!mcc-db2!ables

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

Date: 21 NOV 85 14:30-N
From: APPEL%CGEUGE51.BITNET@WISCVM.ARPA
Subject: EAN electronic mailing on Sun workstations
Reply-To: appel@cui.UUCP (Ron Appel)
Organization: University of Geneva, Switzerland


Did anyone install the EAN mailing system on a Sun workstation
running 4.2-Bsd ?

Are there problems and what are they ?

                                        --ra

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

Date: Sat, 23 Nov 85 04:40:58 EST
From: allegra!mp@seismo.CSS.GOV
Subject: file system panics under 2.0

We've noticed that since converting to 2.0, some clients panic
every week or two with a filesystem error.  The messages are generally
freeing free inode, freeing free frag, or dup alloc.  Clients that use
nfs get these panics more frequently.  We even encountered one instance
where when one person manually rebooted his sun, 2 other people who
were on the same disk on the fileserver crashed.

The fileservers have never logged any disk errors or filesystem
problems during these crashes.

Sun tech support thinks it may be a defective xylogics controller, but
putting in a new one didn't fix things and the problem happens on both
of our 2.0 fileservers, anyway.

Our clients are 100's through 160's, all diskless, approximately 10 per
file server.  Our servers are 170's, each with a rev C xylogics 450
controlling 2 eagles.  3 eagles are from Sun.  The eagles are set for
47 sectors/track (I think the extra one is for slipping), and were
formatted/fixed for about 40 or 50 passes each.  I've checked the
partitioning in nd.local; the nd partitions don't overlap.  Almost all
the partitions were initially sized by setup (some were increased in
size when people needed more space, but they're still multiples of 46
sectors); I manually mkfs'ed them as part of the automated installation
of new users here, and checking them with dumpfs shows the sizes are OK.

A side question: frequently after the panic, fsck complains about
an unallocated file called /etc/zz######, where # is a digit; does
anyone know where this comes from?

	Mark Plotnick
	allegra!mp

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

Date: 26/11/85 16:35 
From: mcvax!inria!ralph@seismo.CSS.GOV
Subject: Sun vs. Apollo

The audience of this question is the people who have had to decide
between Sun and Apollo workstations.  With the advent of Sun-3s and
Apollo DN330s the decision gets harder:
1)	The processer is the same,
2)	Sun is a Unix machine and Apollo gives us 2 Unix's,
3)	similar price, etc.

I would very much appreciate any insight into the reasons for which
one machine was bought rather than the other.  Please reply to me
directly, and if there is interest I will post a summary to the net.

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

Date: Wed, 27 Nov 85 16:58:36 EST
From: Steve M. Burinsky <smb@mimsy.umd.edu>
Subject: problems with serial ports on zs board

I have a Sun-3/160C with a Zilog 8530 board, which provides two serial ports.
It is configured in as shown in zs(4s).  When I enable ttya in /etc/ttys and
kill -HUP 1, a getty process starts running on that line.  The problem is that
it doesn't stop running!  This chews up the CPU with interrupts.  Getty will
only change its state (to S or I) when a terminal is physically connected to
the port, which is something I can't guarantee on my system.  

Has anyone run into this problem?  Any clues/suggestions?  The only remedy I
can think of is to put some type of termination on the line when a device is
not connected.

Thanks in advance,
Steve Burinsky

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

Date: Wednesday, 20 November 1985 18:35:30 EST
From: Dan.Miller@a.sei.cmu.edu
Subject: Survey -  Window Managers/User Interfaces and Dist. File Systems

     WINDOW MANAGERS/USER INTERFACES and DISTRIBUTED FILE SYSTEMS:
                       Survey ---> Need Your Help

I  want  to  put  together  a  COMPLETE  list  of  WINDOW  MANAGERS/USER
INTERFACES and DISTRIBUTED FILE SYSTEMS (either bundled together  in  an
integrated  system  or separate), specifically products, prototypes, and
university "freeware".

I'd like to hear from EVERYONE,  across  all  countries,  organizations,
hardware,  OSs,  etc., so a MEGA-list of ALL known systems can be posted
back to the net.

I am sure everyone who reads the summary will appreciate your effort  in
jotting  down  the  names,  developing  organizations, references, short
statements of functionality / capabilities / uniqueness, host  machines,
OS, etc., of systems you are working on or know of in these areas.

Direct replies to

             dhm@sei.cmu.edu (dhm@cmu-sei.arpa) [Internet]
                ...!ihnp4!seismo!dhm@sei.cmu.edu [UUCP]

--- Daniel "Dan" H. MIller                Software Engineering Institute
dhm@sei.cmu.edu (dhm@cmu-sei.arpa)        Carnegie-Mellon University
(412)578-7700                             Pittsburgh, PA 15213 USA

"Disclaimer:  The  views  and  conclusions  are those of the author, and
should not be interpreted as representing the official policies,  either
expressed or implied, of any organization he may be affiliated with."

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

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