SUN-Spots Digest, v4n34
Sun-Spots-Request at RICE.EDU.UUCP
Sun-Spots-Request at RICE.EDU.UUCP
Sat Dec 13 08:10:15 AEST 1986
SUN-SPOTS DIGEST Friday, 12 December 1986 Volume 4 : Issue 34
Today's Topics:
NeWS-makers mailing list
Rasterfile to IMPress
SunTroff
Sun woes
Sun discussions in Unix-Wizards
MIP-1024 or 512 on Sun 2/160 or Sun 2/120?
Timed for Sun 3.X?
How many diskless workstations can you put on an ethernet?
Third part peripherals for SUN 3?
Synch over Sun serial ports?
Excelan Ethernet board on Sun?
Pixar computer on the Sun workstation?
uucp problem?
windowing software and graphics functions on 3/160?
Kyoto Common Lisp (KCL)?
CADroid for Sun-3?
NeWS Worthy? (very long)
Tape drive recommendation for a sun-3/160?
Ethernet traffic metrics: measuring incremental traffic?
NFS reliability?
hostid on suns?
------------------------------------------------------------------------
Date: Mon, 17 Nov 86 14:23:42 EST
From: Don Hopkins <don at brillig.umd.edu>
Subject: NeWS-makers mailing list
This is to announce the inception of a mailing list for the discussion
of NeWS: the Network/extensible Window System. Its Internet address is
"NeWS-makers at brillig.umd.edu", and the uucp address is
"...!seismo!mimsy!NeWS-makers". Administrivial matters (such as
requests for additions to and deletions from the list) should be sent
to NeWS-makers-request. The studly capitalization of the address is
not necessary.
NeWS, originally called SunDew, was written primarily by James
Gosling, at Sun Microsystems, who is well known for his Unix Emacs. In
a nutshell, NeWS is an extensible multitasking window system
environment. It consists of a network based display server that is
controlled and programmed in PostScript, Adobe's page description
language. NeWS was designed to be a portable, device independent
window system development platform that runs on a wide range of
hardware, in a distributed heterogeneous environment.
Within the address space of the NeWS server, lightweight PostScript
processes communicate and interact with each other by sharing data,
and passing around events and messages. Clients may communicate with
processes by sending them PostScript commands and source code, that is
interpreted and executed in the server, or by invoking functions in
the server that communicate in different ways. PostScript running in
the NeWS server can implement whatever protocols and data compression
schemes are useful for communicating with clients. NeWS provides the
tools to implement the user and programmer interfaces of other window
systems, such as SunView, Apple Macintosh, Interlisp-D, MS Windows,
and even the X window system.
NeWS is to most other window systems as Emacs is to most other
editors. There is no doubt that extensible systems allow degrees of
freedom that "hard wired" systems simply cannot provide.
-Don
(don at brillig.umd.edu, ...!seismo!mimsy!don)
------------------------------
Date: Wed, 19 Nov 86 21:32:02 pst
From: "David L. Markowitz" <ames!seismo!csuf.ARPA!davstoy!dav at cad.Berkeley.EDU>
Subject: Rasterfile to IMPress
I have been unable to reach any of the people who asked me for a
copy of rastimp (rasterfile to IMPress converter). Please mail
your address to me again. Make sure it is reachable from uucp.
New requests will be honored also.
David L. Markowitz (Real Time Trekker)
Rockwell International (Where Science Gets Down To Busyness)
...!ucbvax!trwrb csustan
\ /
...!sdcsvax!ucivax!csuf!davstoy!dav
/
...!hplabs!felix
------------------------------
Date: Tue, 25 Nov 86 19:03:09 CST
From: Bill Janssen <janssen at mcc.com>
Subject: SunTroff
Way to go! I've been using the previewer from Andrew, and it's a true
pain to flip between the two window systems. The thanks of a grateful
public...
Bill
------------------------------
Date: Thu, 27 Nov 86 12:01:17 EST
From: mark at markssun.cs.umd.edu (Mark Weiser)
Subject: sun woes
cc: mike at bellcore.com
I share all your concerns. I can pass on some rumors (well, not
rumors actualy--Bill Joy stated them in front of 1000 people, but
Sun won't put them in writing):
Two things are getting fixed in release 4.0 of the sun operating system
(which will be beta testing this spring, real release not until fall '87):
1. shared libraries, which will drastically reduce the 500k size of
window-knowledgeable processes. This may not help with the link time,
however.
2. NeWS-the new window system, which even without shared libraries
cuts way down on how much each process has to include in its local
window knowledge. This WILL cut ld time.
3. ND is going away with 4.0, to be replaced with exactly your suggestion:
the ability to swap to any file.
-mark
------------------------------
Date: Mon, 17 Nov 86 18:25:43 PST
From: hoptoad!gnu at lll-crg.ARPA (John Gilmore)
Subject: Sun discussions in Unix-Wizards
Here are a few very-Sun-specific messages from Unix-Wizards, which
the readers of Sun-Spots will be interested in...
Date: 18 Nov 86 02:13:24 GMT
From: hoptoad!gnu (John Gilmore)
Subject: Discussions very specific to Suns should go to mod.computers.sun too.
Lately I've seen a bunch of messages talking about Suns in unix-wizards.
People wanting to buy black market Suns :-), figure out how many diskless
machines fit on one Ethernet, etc. I'd just like to remind you-all
that mod.computers.sun is the main forum for this kind of questions.
A lot of people have lost patience with unix-wizards but still read
Sun-Spots or mod.computers.sun (they are gatewayed to each other).
--
John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu jgilmore at lll-crg.arpa
"I can't think of a better way for the War Dept to spend money than to
subsidize the education of teenage system hackers by creating the Arpanet."
Date: 11 Nov 86 23:32:46 GMT
From: jay at isis.UUCP (Jay Batson)
Subject: Used suns...
Just a couple of questions - it's option exploring time for me.
1) Does anybody sell their used Suns when they buy newer Suns/other
equipment or when they close their doors, or do they all simply get
moved to the "old equipment to keep around" room?
2) Last time you knew of one getting sold, what model was it and what
did it go for? I've worked where we've had and sold other, fairly major
brand super-micro's before, and do Sun's depreciate as fast as other
equipment does?
3) Has anybody who bought a used Sun had difficulties getting new
OS releases and other occasionally necessary assistance from
Sun because you didn't buy the box from them? What has been
the cost of 'software maintenance' (i.e. the program you have
to be on to get new OS releases), vs. the cost of simply paying
for a new release every year or two when the need becomes overwhelming?
4) I've only had a small! amount of time to work on Suns, but what I
did do I loved. I've never looked at the hardware configuations
like serial ports, etc. though. What do you get on the backplane
of the system, e.g. serial/parallel ports and #, & could you
hang an ascii terminal off one of them? I could use a summary
of the model numbers, and what distinguished them from the next,
more 'glorious' models, along with as objective, factual comparison
of performance between them as possible if you can say. (Guy
Harris - are you reading this???)
5) What configuration would be reasonable for a stand alone system?
I've seen the workstation hooked to a small box containing
fuji disc and streamer. I assume this is the way to configure it.
What are the inherent limitations in this kind of setup given the
way Sun designed it?
6) What are the deadly problems to watch out for on the older boxes,
and how many of these were really OS bugs that are fixed if you
get a current release? The primary use will be C applications
development, with non-sun targets (e.g. law office software
for other, small UNIX based systems using ascii terminals).
7) I _do_ have occasion to need to use DOS stuff, and I'm going to
have to deal with that at the same time. Certainly, a small
clone might be the best bet, but I'd like some comments
on Sun's DOS co-processor board, and running DOS as a process;
e.g. what are the "compatibility" limitations, how interested is
Sun in making it work, does 'lotus' run, etc, cost of the board
and DOS from Sun or used.
8) Anybody out there have any boxes they plan on selling in the next
few months??? Of course, I'll read responses to 1) - 7) from
people who do have one to sell with an appropriately skeptical eye.
All help appreciated. Please excuse the 'wizards' group choice - I know
I should have posted it to net.wanted, but this is really as much as
a fact-finding posting as an offer to buy, and 'wizards' are as
likely as anybody to know the answers to this. I'm still exploring
alternatives for an anticipated project. Thanks in advance.
--------
"Stop it!! Stop it now. This is getting silly again, and this silliness
has _got_ to stop. Go on to the next sketch. Go on. Turn this camera o "
Jay Batson
ihnp4!onecom!\
isis!jay
seismo!{hao,nbires}!/
Date: 14 Nov 86 00:24:18 GMT
From: eeproks at gitpyr.gatech.EDU (K. J. Seefried iii)
Subject: used SUN's
I would also be very interested in information concerning the purchase
of used Sun's and other used Unix boxes. I am a student interested in
the purchase of a personal Unix system. Any comment's or suggestions
would be greatly appreciated.
K. J. Seefried iii
P.O. Box 30104, Georgia Insitute of Technology, Atlanta Georgia, 30332
...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!gitpyr!eeproks
------------------------------
Date: Fri, 14 Nov 86 08:19:59 est
From: munnari!csadfa.oz!gyp at seismo.CSS.GOV (Patrick Tang)
Subject: MIP-1024 or 512 on Sun 2/160 or Sun 2/120?
The Computer Science Department and the Electrical Electronics Engineering
Department in this campus have just recently purchased MIP-1024 (Real-Time
1024 x 1024 Image processor) to be installed on SUN 2/120 and SUN 2/160
respectively. The SUN 2/120 is a Multi-bus system while the SUN 2/160 is a
VME-bus system.
The Electrical Electronics Engineering Departments has begun their first
stage of installation, ie with one MIP-board configuration. (The final
configuration is 3 MIP-1024 composed of 1 master and 2 slave to produce
colour images). However, a problem has been encountered during the process,
>driver for the MIP is able to do all sorts of good things with the I/O ports,
>but appears to fall over when trying to address the bulk memory of the MIP
>(ie the frame buffer).
I wonder anyone who has such system could give us any help. In addition,
does anyone understand the address-mapping which occurs at the hardware level,
in order to be able to use the SUN Monitor to properly check hardware registers
and bulk memory locations.
Any other problems that you had encountered and method of solving them during
the process of installation of the MIP-1024 or MIP-512 for the VME or Multi-bus
SUN would be most appreciated as well. We would appreciate it very much if you
could define clearly which MIP configuration and SUN system that you are
talking about.
Thanks in advance.
----
Tang Guan Yaw/Patrick Phone ISD: +61 62 68 8819 STD: (062) 68 8819
Dept. Computer Science Telex: ADFADM AA62030
University College ACSNET: gyp at csadfa.oz
Aust. Defence Force Academy UUCP: ...!seismo!munnari!csadfa.oz!gyp
Canberra. ACT. 2600. ARPA: gyp%csadfa.oz at SEISMO.CSS.GOV
AUSTRALIA CSNET: gyp at csadfa.oz
------------------------------
Date: Sun, 16 Nov 86 18:28:13 EST
From: Ken Mandelberg <km at EMORY.ARPA>
Subject: Timed for Sun 3.X?
Has anyone made the new 4.3 timed work on Sun 3.X?
The 4.3src does have provision for a 68000 based machine (for the checksum
code), but the 4.2-4.3 differences cause a bunch of errors in the make,
mostly because of changes in the network code from 4.2 to 4.3.
------------------------------
Date: 17 Nov 86 16:50:08 GMT
From: mlandau at Diamond.BBN.COM (Matt Landau)
Subject: How many diskless workstations can you put on an ethernet?
I need some information on how to measure and compute meaningful metrics
about ethernet performance and traffic levels, in particular about "the
amount of traffic generated" by adding diskless Sun 3's to a local ethernet.
Let's say I have a hypothetical network in place, and I want to put, say,
30 diskless Suns (a mix of 3/50's, 3/75's, and 3/110's) and a couple of
servers (3/160's and 3/260's) on it -- is there any way to estimate how much
traffic I'd be generating, assuming a "standard" mix of edits, compiles, a
few Lisps here and there? What if I wanted to put 100 diskless Suns and
maybe 10 or 15 servers on one ethernet? 500 diskless and 50 servers?
In other words, I'd like to be able to figure out just how far can one
push a single ethernet before it gets swamped? Any useful ideas, either for
measuring the numbers or from experience with large numbers of diskless
machines? (Sun, are you listening, and can you tell me how this is handled
at SMI?)
--
Matt Landau BBN Laboratories, Inc.
mlandau at diamond.bbn.com 10 Moulton Street, Cambridge MA 02238
...seismo!diamond.bbn.com!mlandau (617) 497-2429
------------------------------
Date: Wed, 19 Nov 86 23:33:41 EST
From: tso at ROCKEFELLER.ARPA (Daniels Tso(Wiesel))
Subject: Third party peripherals for SUN3 ?
What are peoples' experiences with third party peripherals for
the SUN 3?
I understand that Interphase makes a real VME/SMD controller
which is supposed to work well with the SUN 3. Has anyone used it ?
What is the feasibility of order a SUN 3 without any disk and buying
the Interphase and an Eagle and bringing up SUN Unix ?
How about tape controllers ?
Why (other than historically) are SUN's controllers Multibus ?
I believe SUN still uses an old Xylogics disk controller even though
Xylogics now makes a VME controller.
Thank.
Dan
rna!dan at cmcl2.arpa
...cmcl2!rna!dan
------------------------------
Date: Tue, 25 Nov 86 05:18:02 EST
From: mark at markssun.cs.umd.edu (Mark Weiser)
Subject: Synch over Sun serial ports?
Do the normal pair of sun serial ports brought ought to the back
have enough hardware behind them to support externally-clocked
synchronous communication (at 56kb)? I presume so, since
there are Sun products which talk to them this way.
Where can I find the specifications for programming these ports
synchronously? The ZS manual entry refers to a piece of documentation
called 800-1052-1 (or at least that is its name, it probably
isn't called that).
I am thinking about using Interoffice LAN from the phone company
to connect a couple of semi-distant Suns using SLIP and synchronous
communication at 56kb. Anyone with experience to share about any
piece of this, I'd like to hear from you. (I currently connect
these Suns using SLIP over AJ 4800 baud modems over the switched
network, but the AJ's are slowly dying and I am looking into a soon
replacement).
-mark
------------------------------
Date: Wed, 26 Nov 86 20:49:52 pst
From: hplabs!pyramid!utzoo!henry at ucbvax.Berkeley.EDU
Subject: Excelan Ethernet board on Sun?
Has anyone ever tried adding the Excelan VMEbus Ethernet board to a Sun-3?
On paper it looks possible. We may have a requirement for which it would
be very desirable to put a *smart* Ethernet controller on our 3/180S. It's
not clear to me just which controller Sun sells as its add-on one, but some
things in the manuals hint to me that it's the old 3Com unintelligent one.
This doesn't thrill me. Being able to download TCP/IP into the Excelan
board is of particular interest to us. Any experience with this particular
combination, or similar alternatives?
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
------------------------------
Date: Thu, 27 Nov 86 17:41:10 est
From: munnari!yarra.OZ!richb at seismo.CSS.GOV (Rich Burridge)
Subject: Pixar computer on the Sun workstation?
I am asking this question on behalf of one of my customers. Apologies
for it's vagueness.
"Has anybody heard of a Pixar computer that is connected to a Sun
workstation?
I understand that Lucas Film use them for animation. Who sells them ? "
Regards Rich.
Rich Burridge ISD: +61 3 267-6222
Sun Australia STD: (03) 267-6222
14 Queens Rd, ARPA: richb%yarra.oz at seismo.css.gov
Melbourne, VIC 3004. UUCP: seismo!munnari!yarra.oz!richb
AUSTRALIA. ACS: richb at yarra.oz
------------------------------
Date: 28 Oct 86 11:22:59 PST (Tue)
From: petel%teksce%tektronix.csnet at CSNET-RELAY.ARPA
Subject: uucp problem?
I'm looking for someone who could help me make a Concord Data Systems
224 Series II modem work with a SUN 3/160 as both a dialout/dialin
modem (ttya converted to ttyd0/cua0), and where I'm having problems,
with UUCP.
Pete Lancashire uucp: ..!tektronix!tekgen!teksce!petel
Tektronix Inc. (503) 627-2566
------------------------------
Date: 28 Oct 86 11:23:43
From: jmf%vanderbilt at csnet-relay (Mike Fitzpatrick)
Subject: windowing software and graphics functions on 3/160?
I would like to hear from someone who has a 3/160 or 3/260 with the display
configured for 1024 x 1024 pixels. Do the windowing software and graphics
functions work properly in that mode? I would prefer 1024 x 1024 so that I
can display complete images of that size in my medical image processing work.
I would also like to know of image processing software available for the Sun.
Mike Fitzpatrick
Department of Computer Science - Box 80 B
Vanderbilt University
Nashville, TN 37235
jmf%vanderbilt at csnet-relay
------------------------------
Date: Wed, 29 Oct 86 16:51:05 -0200
From: mcvax!lifia!schnoebe at seismo.CSS.GOV (Philippe Schnoebelen )
Subject: Kyoto Common Lisp (KCL)?
I am using Kyoto Common Lisp (KCL) on a SUN3 workstation. KCL compiles Lisp
into C, which provides a very easy interface between Lisp and C. Now, it
should be easy to write a Lisp package that would give direct access to all
graphics, windowing, .. toolbox and system functions, basically all you have
to do is to find names for your Lisp functions and to write the standard
interface code for every one of them.
Well, this should be easy but if anyone has already done it, I would really
prefer to use his code rather than writing it myself (and then debugging it).
Anybody has ?
Much thanks in advance,
--
Philippe SCHNOEBELEN,
LIFIA - IMAG, BP 68 UUCP : ...mcvax!imag!lifia!phs
38402 Saint Martin d'Heres, FRANCE
"Algebraic symbols are used when you do not know what you are talking about."
------------------------------
Date: Wed, 29 Oct 86 15:56:21 EST
From: princeton!stern at seismo.CSS.GOV
Subject: CADroid for Sun-3?
Does anybody have information on CADroid for the Sun-3? CADroid is
a Lucasfilm product, used for schematic capture and layout generation.
I've heard about it being used on Sun-3s and would be interested in
bringing it up here.
Mail replies are appreciated.
--Hal Stern
Princeton University
{ihnp4, allegra, seismo}!princeton!stern
------------------------------
Date: Fri, 31 Oct 86 18:13:47 PST
From: vern at lbl-csam.arpa (Vern Paxson [rtsg])
Subject: NeWS Worthy?
[forwarded from xpert at athena.mit.edu]
Date: Thu, 30 Oct 86 09:55 EST
From: Robert Scheifler <RWS at zermatt.lcs.mit.edu>
Subject: NeWS Worthy?
To: xpert at athena.mit.edu
NeWS Brakes
Robert W. Scheifler
MIT Laboratory for Computer Science
October 30, 1986
Since Sun's announcement of NeWS, many people have asked me "Who will win?"
(X versus NeWS). I cannot, of course, pretend to know the answer to this
question. However, from the relative safety of my ivory tower at MIT, I
can pretend that the more interesting question is "Who is right?"[*]. The
following note attempts to answer this question; these are my personal
opinions, and should not be construed as the opinions of my employers or of
anyone else. My understanding of NeWS comes from [1] and [2]. For the
most part, I will confine myself to relatively high-level issues, since [1]
contains very few details. I assume the reader has read [1], and is
reasonably familiar with X. In the following, I refer to X Version 10
simply as "V10", and X Version 11 as "V11".
Downloading: Panacea or False Hope?
An interesting feature of NeWS is the ability to download code
(specifically PostScript) into the server. Sun claims this is a solution
to latency problems otherwise incurred with IPC round-trips, for example,
when animating objects on the screen in response to mouse motion. They are
fairly careful in not giving menu highlighting and window outline rubber
banding as examples of this. On a uni- or multi-processor with IPC based
on shared memory, latency (and bandwidth) is unlikely to be an issue. V10
has shown quite clearly that even the relatively long network latencies
under current Unix implementations is not a problem for simple forms of
tracking[**], and it is clear (from systems like the Stanford V kernel and
the Xerox Cedar system) that a 5x to 10x reduction in latency is to be had
even on existing hardware. Solving the problem at the network level
reduces complexity not only in window systems, but in many other
distributed systems as well. Also, we have seen many V10 applications that
are actually faster when client and server are placed on separate machines,
simply because more CPU cycles are available.
If downloading is not particularly important for simple tracking, perhaps
it is useful for more complex tracking. So, let's consider an example of
complex tracking, based on (but not identical to) the Symbolics Genera
window system [3]. This is but one example, there are plenty of others
(even in current V10 applications).
We have a large collection of objects displayed in the window. Each object
is responsible for displaying its contents, but the application at a higher
level keeps track of the visual extents of the objects. Each object also
defines what operations can be performed on it, and what accelerators
(key/button combinations) can be used to execute some of those operations.
As the mouse is moved over an object, the object is asked to highlight
itself, and to produce a string documenting the possible accelerators
(based on the current key states); the string is displayed at the bottom of
the screen. In addition, objects may be used as arguments to commands
typed from the keyboard. For example, when typing the command "Show
Directory", only objects (such as file pathnames) capable of supplying a
directory name are active (i.e., highlight when the mouse is over them),
and all other objects become inactive. This is accomplished by querying
the objects dynamically as the mouse moves, to see if they are both willing
and capable of producing a given type of value.
It should be clear from this example that there is no reasonable functional
separation that would allow a front end to be downloaded into a server in
such a way as to avoid round-trip communication. The tracking is
intimately bound to the semantics of objects. In general, a front end
performing complex tracking will require access to much the same data
structures and knowledge representations used by the back end for the
"real" work. Separating out the information will be painful at best, and
even if the relevant information could be isolated or even duplicated in
the server, the communication costs have merely been moved (the information
has to be kept up to date somehow), not eliminated.
Even if one could download a front end into the server, would one really
want to? PostScript may be Turing complete, but if my front end is at all
large or complex, I certainly do not want to write it in PostScript. I
presumably already have a wonderful language and environment for writing my
applications (e.g., Flavors, CommonLoops, C++); should I really believe
industry/academia is going to start providing compilers to PostScript?
Noticeably absent from [1] is any discussion of debugging; the print/dump
operators that are mentioned indicate a giant step backward in debugging.
In addition, one must be wary of assuming that the processing power of the
server is at least as great as the power of the client. Although this is a
reasonable assumption for graphics output specifically, exactly the
opposite will almost always be true for general computation, given both
typical hardware (do you really think my "terminal" is going to have a
faster CPU and more physical memory than whatever machine I use to run my
"real" programs?) and compiled (in the client) versus interpreted (in the
server) execution. (It would be interesting to know how much of the
interpreter and graphics substrate in NeWS is written in PostScript.)
Sharing and malleability of "common" user interface components is cited by
Sun as being significant considerations; menus are given as a specific
example. To allow sharing and wholesale replacement of components,
interfaces must be defined precisely and agreed upon universally. At this
level of programming, agreement in the real world seems highly unlikely;
one needs only to look at the menu interfaces of existing window systems to
realize that, although they have much in common, they differ quite a bit in
detail. Furthermore, commercial interests tend to prize "tamper-proof"
packaging highly, to minimize service and maintenance headaches.
The Imaging Model
Sun apparently believes they can provide X emulation on top of NeWS. This
is simply not possible for color displays, given the PostScript imaging
model. What is true is that PostScript emulation on top of V11 is
straightforward, either done entirely on the client side, or in combination
with an upward compatible extension to the V11 core protocol.
Although NeWS allows the setting of a "current RasterOp function"
explicitly for "backward compatibility", the ability to restrict the
operation to a subset of the hardware planes appears to be absent.
Further, NeWS has no concept of colormaps, and hence no concept of
arranging for pixel values to have particular relationships, and no concept
of diddling the colormap to change colors dynamically without repainting
the image. These mechanisms are of vital importance not only to
sophisticated imaging and CAD applications, but to "everyday" applications
(like xterm) as well.
For example, the ability (by clever arrangement of pixel values and by
restricting graphics to particular planes) to highlight and un-highlight
regions without redrawing, or to draw and erase foreground text without
affecting background images, is crucial for high performance. This trick
is used in many V10 applications, and the V11 colormap allocation
primitives allow such games to be played in a reasonably device-independent
fashion. NeWS has an "overlay" mechanism which attempts to provide
equivalent functionality. However, the overlay semantics appear to be so
ill-defined (e.g., no guarantees about color or performance) as to be
nearly useless. One of the important lessons we learned from V10 was that
attempting to define something so vaguely that it can be always be
implemented in some fashion simply results in a mechanism so unpredictable
that no one dares use it. V11 has explicitly steered clear of attempting
to "standardize" overlay semantics, yet provides a window class mechanism
by which overlays can be added in an upward compatible fashion.
Although Sun claims that NeWS, by virtue of its abstraction, will provide a
better match than X with future graphics hardware, the opposite actually
seems to be true. V11 has been designed explicitly with future hardware in
mind. Next generation hardware will allow (within limits) a separate
colormap per window, with colormaps of various types (e.g., both
pseudo-color and direct-color). V11 provides direct support for this
hardware. Since a PostScript client provides no "up front" indications of
color usage, heuristics on the part of a NeWS server are unlikely to
perform as well as specific engineering in V11. Future hardware (such as
the Cambridge Rainbow [4]), supporting variable depth windows with the
hierarchy implemented in silicon, has also been accounted for in the V11
design; both windows and off-screen images of varying depths can be
supported. Again, lacking up front resource requirements from clients, a
NeWS server cannot hope to match the minimum memory allocation that is
possible in V11.
Sun apparently believes that, by hiding the true size of the colormap, they
can do a better job of keeping all windows at "true" color than a V11
server can. Once clients have already displayed in "too many" colors,
which server can do a better job of picking the "best" colors to display?
The answer is that a V11 server has the same information as a NeWS server,
and so can make the same decision. However, a V11 server also has
additional information, in the form of what logical colormaps are "most
desirable" to display, so perhaps a V11 server can actually do better than
a NeWS server. One might think that a NeWS server could do better by
limiting colors as they are used by clients, by using various color
approximations. However, to do this effectively requires prior knowledge
of how many colors clients will use, and which of those colors are most
important. PostScript provides no such declarative mechanism. (Achieving
the effect by forcing clients to redraw their windows would of course be
quite unacceptable.) The same problems exist for playing anti-aliasing
tricks; there is no mechanism in PostScript to indicate where anti-aliasing
will be most helpful. The cause of these problems, of course, is that
PostScript was designed for printers, and printers simply do not have the
same kinds of palette restrictions that displays have.
PostScript (at least according to [2]), does not allow full color images to
be transferred; one must choose between 1, 2, 4, and 8 bit images with a
mapping from N-bit value to color. V11, on the other hand, allows full
color images to be transferred. PostScript also mandates a single image
format, in terms of bit order and byte padding. One of the lessons we
learned from V10 was that this was a bad idea if you wanted good
performance across a variety of hardware. Requiring clients to handle
several different formats is a bit awkward, but substantial performance
improvements are possible as a result.
The coordinate transformation mechanism of PostScript is certainly
powerful, but power can be a double-edged sword. If the display hardware
happens to provide a matching mechanism, then pushing the transformations
into the server can increase performance. However, if the display hardware
cannot do transformations, it is quite likely that the client machine can
perform the transformations at least as fast as the server; delaying the
transformations may actually slow things down (particularly when floating
point is involved). In addition, PostScript transformations are purely
2-D, making the addition of 3-D transformations a bit problematical.
"Convenience" transformations are just as easily performed on the client
side as in the server. Convenience transformations also have their
problems. Although being "off by half of a dot" is not really a problem at
current and future printing densities, screen resolutions now and for quite
a while are not so accommodating (it seems quite unlikely that even
monochrome [much less color] displays with Megascan-like densities will be
on everyone's desktop anytime soon). Precision is vital; "off by one" is
not good enough. Of course, not all transformations are a simple matter of
convenience; true scaling and rotation of a source image are possible in
PostScript. If true scaling and rotation turn out to be important
considerations, the V11 protocol can easily be extended in an upward
compatible fashion to support it. The fact that V11 uses a state-based
protocol (as does PostScript) makes this straightforward.
System Design
The use of lightweight processes and non-preemptive scheduling in NeWS are
not new. Indeed, that is a fundamental problem: the technology is already
dated. Decent operating systems supporting multi-processors, lightweight
processes, shared memory, preemptive scheduling, and efficient
synchronization exist today, and even Unix implementations with such
support are fast becoming a reality. Equally important, next generation
display hardware is quite likely to contain the necessary support for true
multi-threaded use. A true multi-threaded V11 server will be able to take
advantage of all this technology (for example, a true multi-threaded V10
server has already been implemented), but getting a NeWS server to do the
same will be extremely difficult. The decision to use non-preemptive
scheduling is the key here. Certainly this makes life much easier in the
short term, but once you commit to it there is no changing your mind. I
spent the last few years designing and implementing a multi-process
environment for a fairly sophisticated distributed systems language [5]. I
used lightweight processes with semi-preemptive scheduling (preemption
could only occur at certain procedure calls). This certainly simplified
synchronization issues enormously, but the code as it now stands would
require substantial modifications to run in a preemptive or multi-processor
environment.
Event handling in NeWS is another area of concern. Given the "wonderful"
capabilities of PostScript, why are clients restricted to using primitive
component matching to express interest in events? Allowing clients to use
true functions to express interest would provide significantly more
flexibility. Is there some concern here that executing functions will not
be fast enough? One hopes not, or faith in the whole PostScript concept
begins to crumble. Another problem with the NeWS event mechanism is too
much synchronization. In particular, there is no notion of which events
require synchronization. Instead, NeWS guarantees that when an event is
dispatched, the destined processes are guaranteed to run before another
event will be dispatched. This will only serve to slow the server down in
a true multi-process environment. And even in the intended NeWS
environment, what happens if the destined process is busy performing some
other prolonged task (like reading from the network)? In contrast, V11
only requires synchronization at explicit event grabs, which are expected
to be infrequent.
Stability
Both NeWS and V11 claim commitment to stability. The V11 design is based
on concrete experience and feedback from V10. The V11 design has been
reviewed by people in many universities and companies, with very positive
results. This gives me confidence that V11 stability can be a reality. As
discussed above, a number of fundamental design decisions in NeWS leave me
uneasy; if Sun chooses to change them, stability will be lost, but if Sun
chooses not to change them, significant performance will be lost.
[*] This is a perfect example of "language design by implementation". The
two questions are obviously semantically equivalent, but the implementors
have inexplicably chosen to make them different. :-)
[**] People who have only used X on a Sun tend not to believe this. The
implementation on the Sun uses an inferior mechanism for getting input
events from the kernel to the server (select/read on a file descriptor
instead of shared memory), and this significantly affects performance.
[1] NeWS Preliminary Technical Overview. Sun Microsystems, Inc. October 1986.
[2] Adobe Systems, Inc. PostScript Language Reference Manual. Addison-Wesley,
1985.
[3] Programming the User Interface. Symbolics, Inc. 1986.
[4] Wilkes, A. J. et al. The Rainbow Workstation. The Computer Journal 27,2.
May 1984.
[5] Liskov, B., and Scheifler, R.
Guardians and Actions: Linguistic Support for Robust, Distributed Programs.
ACM Transactions on Programming Languages and Systems 5,3. July 1983.
------------------------------
Date: Fri, 14 Nov 86 11:43:38 pst
From: naren <naren%systems.carleton.cdn%ubc.csnet at RELAY.CS.NET>
Subject: Tape drive recommendation for a sun-3/160?
We will be buying a sun-3/160 file server from SMI, but would like to
buy 1/2" tape controller and drive from other sources. Any recommendation
as to what should be bought and what shouldn't? Please mail reply to me
or to the list as appropriate. Thanks.
Narendra Mehta,
Systems & Computer Eng. Department, Carleton University, Ottawa, Canada
UUCP: {allegra,decvax,ihnp4,linus,utzoo}!watmath!clan!naren
CDN: naren at systems.carleton.cdn
ARPA: naren%systems.carleton.cdn%ubc.csnet at csnet-relay.arpa
CSNET: naren%systems.carleton.cdn at ubc.csnet
------------------------------
Date: 17 Nov 86 16:54:15 GMT
From: mlandau at Diamond.BBN.COM (Matt Landau)
Subject: Ethernet traffic metrics: measuring incremental traffic?
I need some information on how to measure and compute meaningful metrics
about ethernet performance and traffic levels, in particular about "the
amount of traffic generated" by adding diskless Sun 3's to a local ethernet.
Let's say I have a hypothetical network in place, and I want to put, say,
30 diskless Suns (a mix of 3/50's, 3/75's, and 3/110's) and a couple of
servers (3/160's and 3/260's) on it -- is there any way to estimate how much
traffic I'd be generating, assuming a "standard" mix of edits, compiles, a
few Lisps here and there? What if I wanted to put 100 diskless Suns and
maybe 10 or 15 servers on one ethernet? 500 diskless and 50 servers?
In other words, I'd like to be able to figure out just how far can one
push a single ethernet before it gets swamped? Any useful ideas, either for
measuring the numbers or from experience with large numbers of diskless
machines? (Sun, are you listening, and can you tell me how this is handled
at SMI?)
Please reply by mail, and I'll summarize if there's any interest.
--
Matt Landau BBN Laboratories, Inc.
mlandau at diamond.bbn.com 10 Moulton Street, Cambridge MA 02238
...seismo!diamond.bbn.com!mlandau (617) 497-2429
------------------------------
Date: 12 Nov 86 22:35:44 GMT
From: jeff at tc.fluke.UUCP
Subject: Re: NFS reliability?
In article <1823 at rlvd.UUCP> mike at louis.UUCP () writes:
>Recently we have been doing a study of NFS fileservers and we have
>come across unreliability in NFS (i.e writing something to a remote
>file and finding something different when reading it back) when the
>server was under extreme load. Now we are starting to notice the same
>behaviour on our existing Sun fileservers.
>The question is, have other noticed this and does anyone know why
>it happens? And, of course, does anyone know how to stop it?
>Mike Woods
We have also experienced a (rare) phenonenon which does seem limited to
NFS files: a file may have a (logical) block's worth of data written as nulls.
It appears to happen under some ill-defined conditions of simultaneous access.
We've only seen it with /usr/spool/mail files and RCS *,v files (ouch!).
We've suffered another you-don't-get-back-what-you-wrote bug, but it is
NOT limited just to the NFS. (If you serve diskless clients, they will
also see panic: ifree's.) Turns out to be a problem with the Xylogics 450
disk controller under heavy load; we fixed it by putting each disk on a
separate controller.
--
Jeff Stearns (206) 356-5064
John Fluke Mfg. Co.
P.O. Box C9090 Everett WA 98043
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!jeff
------------------------------
Date: Mon, 17 Nov 86 15:07:15 est
From: msudoc!lawitzke at ihnp4.UUCP (John Lawitzke)
Subject: hostid on suns?
The SUN3/75 stores it's hostid somewhere in ROM. On most systems this is done in
software. I am interested in which ROM on the CPU board and which locations
in that ROM hold the hostid.
John H. Lawitzke UUCP ...ihnp4!msudoc!lawitzke
Division of Engineering Research
364 Engineering Bd. Office: (517) 355-3769
Michigan State University Home: (517) 332-3610
E. Lansing, MI, 48824
------------------------------
End of SUN-Spots Digest
***********************
More information about the Mod.computers.sun
mailing list