Sun-Spots-Request@RICE.EDU (Scott Alexander) (11/20/85)
SUN-SPOTS DIGEST Monday, 19 Nov 1985 Volume 3 : Issue 11
Today's Topics:
digestification
Streaming 1/4 in. tape
re: why we use ascii terminals at Rice
Different systems on different clients on same server
Re: Mixing Sun-2's & Sun-3's
mods to suntools window manager
3com bottleneck
Memory for the Sun 100U
68k cross complier
help with real world interfaces
Experience with Diskless Suns in a Net with a Terminal Concentrator
Sun-3's as timesharing machines
SunWindows Wish List
------------------------------------------------------------------------
Date: Tue, 19 Nov 85 18:50:45 CST
From: Scott Alexander <sun-spots-request@rice.edu>
Subject: digestification
The consensus seems to be that one week is an acceptable time between
digests. Comments seemed to indicate a strong unhappiness with any delay
longer than this. Comments protesting the amount of drivel on undigested
lists also were strong. Thus, I shall try to issue digest on a weekly basis
for a period. Some time next semester, I'll take another poll to see if
these results are satisfactory.
Scott
-----------------------------
Date: Mon 11 Nov 85 14:03:45-PST
From: Fernando Pereira <PEREIRA%sri-candide@sri-marvin.arpa>
Subject: Streaming 1/4 in. tape
I normally use a block size of 126 (magic number mentioned somewhere
in the documentation), and the tape seems to move forward smoothly. With
other blocking factors, it seems to spend most of the time moving to
and fro.
-- Fernando Pereira
-------
-----------------------------
Date: Wed, 13 Nov 85 11:38:57 est
From: mike%bambi@mouton
Subject: re: why we use ascii terminals at Rice
"We use the terminal for editing and the console for full-screen sorts
of things."
I think it's safe to say that most of us use(d) the ASCII terminal
for running programs that took over the entire console bitmap
(specifically, the Rice R^n programming environment) under dbx.
Most people used a hacked version of Emacs that ran under SunTools
almost exclusively for editing.
With some amount of effort, the R^n system could have been run under
SunTools itself, obviating the need for the ASCII terminal.
- Mike
[My perceptions are somewhat distorted by the fact that most of the work I did
on a Sun with a high contention was just before a demo. The Sun I had been
using lost its keyboard at that time. I still feel that a Sun with a terminal
is a usable work environment from my experiences in times such as this.
---dsa]
-----------------------------
Date: Tue, 19 Nov 85 13:45:23 pst
From: alberta!marius%ubc.csnet@CSNET-RELAY.ARPA
Subject: Different systems on different clients on same server
As shipped from SUN, all diskless clients serviced by the same server
automatically boot the same version of the system (/pub/vmunix).
For installations that have widely varying configurations of clients
this can be inconvenient and you may wish to run differently configured
systems depending on the type and hardware configuration of each client.
We have decided to add an intermediate boot step to the auto-boot process
and each of our clients now has the capability to run a system tailored to
its hardware configuration. We do this based on the client's serial number
as read from the ID-PROM. This method is exceedingly simple and requires
no changes to the boot PROMs. The intermediate boot-step is only ~400 bytes
to find the serial number (works on SUN-2's, but has not been tested
on SUN-3's).
If anyone is interested, the code to achieve this is available (if
SUN gives permission to distribute to sites without a source license).
Maybe this is not considered a problem or is there some obvious solution
that I have completely missed!? - if so, someone please enlighten me.
Marius Olafsson
Dept. of Computing Science
University of Alberta, CANADA
(....ihnp4!alberta!marius)
-----------------------------
Date: Wed, 13 Nov 85 12:40:53 CST
From: William LeFebvre <phil@dione>
Subject: Re: Mixing Sun-2's & Sun-3's
>Roy Smith:
> Much to my surprise, Sun says you can't mix Sun-2's and 3's! They
> can share a cable, but the 2's need a Sun-2 file server; likewise for the
> 3's. Why? If they all talk NFS and ND, what difference does it make who's
> at the other end? This may be a moot point; I'm told there will be a
> software upgrade out by 2/86 to allow mixing.
This is my understanding of the problem -- it may not be completely
correct.
The problem has little or nothing to do with changes in ND or NFS. The
problem stems from Sun's policy of "one server--one kernel". Sun sets
things up so that the same kernel is booted on a server and all of its
clients. Whenever a client boots, the server sends to it the same
kernel image with which the server was booted. That is, there is only
one kernel living on a server, regardless of the type or configuration
of the client CPUs that the server serves. Consequently, a server's
kernel must be sufficiently generic to include all the devices on all
the clients served by that server.
When Sun-3s cams along, they had to make a non-trivial number of
changes to the kernel to support it. Unfortunately, they haven't
unified the two kernels yet. And until they do so, one cannot boot a
server with one kernel and have it send out blocks from another kernel.
Naturally, a local environment can be set up so that one server can
handle booting clients that require different kernels (in fact, we have
done this at Rice to minimize the size of the kernel on a particular
machine). But Sun doesn't want to do things this way. So, you must
have a Sun-3 serve a Sun-3 until such time as they have one kernel
again.
This isn't as unreasonable a policy as it seems. I suspect it would
take a good deal of documentation to describe an alternate method to
the average Sun customer. There is an additional problem with the way
we have implemented it here. The default kernel is generic enough to
run on any machine we have, but there are also more specific kernels
that are smaller. The symbolic links are set up on each client's disk
so that /vmunix points to the kernel that is supposed to be booted.
But just typing "b", or autobooting after crash, will boot the default
kernel. Then anyone that tries to get stuff out of the kernel (nlist
"/vmunix" and lseek around in "/dev/kmem") will not get the right
/vmunix and thus not the right pointers into the kernel. Not only will
"ps" and "w" not work, "sendmail" refuses to do anything since it gets
the wrong figure for the load average. Not very desirable. We are
willing to put up with this problem (sometimes), but I suspect the
average customer would get annoyed after the second or third power
failure.
As far as Sun-2 & Sun-3 machine, I guess we will all just have to wait
until February.
Of course, I could be completely wrong and this message could be just a
bunch of useless drivel. But this is the problem as it was explained to
me.
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.arpa>
or, for the daring: <phil@Rice.edu>
-----------------------------
Date: Thu, 14 Nov 85 12:14:23 EST
From: nbs-amrf!libes@seismo.CSS.GOV
Subject: mods to suntools window manager
I have made a number of useful modifications to Sun's suntools program.
They are as follows:
1) Unified key mechanism. Menu entries may be invoked from the keyboard by
creating a "key" menu (using KEYS instead of MENU in the rootmenu). To
invoke a menu item off the key menu, simply type the tag associated with the
menu. For example, instead of bringing up the menus to refresh the screen,
now I just press "r". To rlogin to our local vax, "v".
2) By pressing the shift key down while the menus are brought up, (a little
"su" appears to the left of the menus and) the next selection is run as
root. This works off the key selections also, so <shift><v> starts up a
su'd shell on our local vax. (Not only is this a convenience, but it
saves you the overhead of the extra su process.)
3) User may specify the primary menu name. (As distributed from Sun, it
must be "Suntools" - bleah.)
4) User may specify shape, rasterop (etc) used by root cursor.
5) Several other keywords are recognized on the menu:
KEYS introduces a key menu.
HELP prints out help.
VERSION prints out version.
EXIT_NOCONFIRM is like EXIT, but it does not confirm that you want to exit.
(I had to put that last one in, in order to support ^D^Q which does not
confirm before exitting.)
I'm willing to distribute these modifications via mail or net.sources,
although I have no way of placing these in an Arpanet archive.
Oh, also, these mods are for 2.0.
I also have a 1.x suntools that has multiple menus. They are compiled in,
however, so you must recompile it to change entries. One menu is dedicated
to rlogins, another to font changes. (And it has the same <shift>-su hack
as the 2.0 version.)
Don Libes {seismo,umcp-cs}!nbs-amrf!libes
-----------------------------
Date: Mon, 18 Nov 85 12:57:36 est
From: Sid Stuart <decwrl!decvax!linus!sid@ucbvax.berkeley.edu>
Subject: 3com bottleneck
I ran across an interesting piece of information at the Sun Users
group conference that may explain some of the network difficulties seen
with Suns. The Sun ethernet board implementations, the
Sun 2 board for 120's and 170's or the on board chips for the 2/50's and
the 3 series, can put packets on the network faster than the 3Com ethernet
board can read. The problem was mentioned at the conference by the Sun engineers
with reference to difficulties between the 3Com board and the 3 series
computers. At Mitre we have a network consisting of 2 2/170 disk servers,
with 3Com boards, and several 2/50 diskless nodes. We have noticed large
delays indicating dropped packets when we write to the disk server from
the 50's.
The problem is supposed to be worse between the 3Com
board and the 3 series computers, so much so that Sun admits to a problem
and may even offer a cheap solution. The Sun representatives at the
conference kept mentioning a possible trade in offer for the 3Com boards:
for $800 and a 3Com board the would give one a Sun 2 ethernet board. I
have not seen anything official from Sun though. I have submitted a
purchase request for the upgrade to my purchasing department and in
two or three months, when purchasing gets through processing it, I will see
what Sun has to say when there is money on the table.
Even if you don't have any 2/50's or 3 series computers on your
system or contemplated in the future you may still to consider upgrading
your diskservers. I was talking to one of Sun's NFS experts, trying to
find out the optimum number of nfsd's to run, he said on a disk server to
increase the number until the cpu usage tops out. When I replied that I
had increased the number to 20 without topping the cpu out, he asked me
if I was running a 3Com board. I replied yes. He said that was the bottleneck.
I wish I could get this kind of information out of Sun without flying to the
west coast.
sid at linus
-----------------------------
Date: Mon, 18 Nov 85 15:21:35 cst
From: oddjob!kaos!sra@lbl-csam (Scott Anderson)
Subject: Memory for the Sun 100U
The standard Sun 100U card configuration only allows two 1-MB memory
boards on the P2 bus with the CPU card; that's what we have now. Is
it possible to use 2- or 4-MB boards, such as from LCF, to increase
the 100U's memory beyond 2MB, or are there limitations besides the
card-cage space that prevent this?
Scott Anderson
ihnp4!oddjob!kaos!sra
-----------------------------
Date: Sun, 17 Nov 85 10:59:34 est
From: ucdavis!lll-crg!seismo!rochester!ur-tut!cam2@ucbvax.berkeley.edu (Craig McGowan)
Subject: 68k cross complier
Does anyone out there know of a public domain (or reasonably priced
commercial) 68k cross-complier running on a Pyramid? We have a Unix source
License, but we would rather not do the port ourselves if possible.
--
Craig McGowan
uucp: ...!{ seismo | allegra | decvax )!rochester!mcgowan
arpa: mcgowan@rochester
-----------------------------
From: munnari!murdu.oz!aes@seismo.CSS.GOV
Date: 13 Nov 85 14:11:13 +1100 (Wed)
Subject: help with real world interfaces
does anyone know how to get d/a interfaces working on a Sun 120??
d/a = digital to analog, for controlling specialised peripherals.
also interested in a/d.
-----------------------------
Date: Thu Nov 14 19:53:48 GMT+1:00 1985
From: mcvax!inria!lasso!ralph@seismo.CSS.GOV (Ralph Sobek)
Subject: Experience with Diskless Suns in a Net with a Terminal Concentrator
We are considering getting 4-5 Sun-3/75m w/o disk and either a Sun-3/160m or
Sun-3/180s as file server with a 380 Mb disk. Each of our diskless Suns
would have 4 Mb of memory in order to run large lisp-based AI programs and
the file-server would most probably have 6 Mb of memory.
Since these machines are reasonably powerful we would like to get something
like a Bridge CS/100 Ethernet interface for up to 14 dumb ascii consoles!
I would like to know if somebody has set up a similar network. Also, does
anyone see any problems? Would the ascii consoles interfere with ND or NFS?
Or much worse, bring down the Ethernet?
Thanks!
Ralph P. Sobek
UUCP: mcvax!inria!lasso!ralph
-----------------------------
Date: Fri, 15 Nov 85 14:30:18 EST
From: Mike O'Dell <mo@seismo.CSS.GOV>
Subject: Sun-3's as timesharing machines
Can anyone out there speak to the performance of an Sun-3 fileserver engine
running as a timesharing box?? I am looking at several alternatives and
would like to know how it fares against (1) a 780, (2) a Microvax II, (3) an
Integrated Solutions/NBI 68020, (4) the Altos 68020 box, (5) the Cadmus
68020 fileserver engine, etc... I understand that peripherals can bias this
whole comparison a great deal, because I am interested in aggregate
throughput, not just cpu speed, so a description of the configurations used
in the comparisons would be useful.
Please mail your replies to me and I will summarize.
-Mike O'Dell
mo@lbl-csam.arpa
mo@seismo.arpa
seismo!mo
-----------------------------
Date: Sun, 17 Nov 85 01:59:15 EST
From: Dan Blumenfeld <DAN@MIT-MC.ARPA>
Subject: SunWindows Wish List
I've used a number of different workstations that use windowing, and
I'm curious as to people's opinions about SunWindows from the user's
standpoint, esp. when compared to other systems.
Some ideas that have crossed my mind are:
1. Transcripting (ala Apollo), i.e. text in a window is preserved
even after it scrolls past the top of the window; the window can
be scrolled all the way back to the point of creation.
2. When a window is resized to be smaller, and is then resized again
to be larger, the text that was obscured reappears. Currently,
this text is lost. Most other windowing systems support this
feature. It would also be nice to be able to pan a window left
and right to reveal text outside the frame, rather than have text
wrap to the next line.
3. "Sensitive areas" on a window to perform sizing, moving, and
closing, similar to the Mac. This would seem to save a bit
of time compared with the "stretch" and "close" procedures
currently implemented.
Any other ideas or comments? Has anyone implemented their own flavor
of SunWindows that supports any of these ideas? I'd love to code this
all up myself, but unfortunately, I'm too involved with writing
applications stuff to get enough time to devote to this. Does Sun
have any plans to enhance their windowing system? Any comments, etc.
are welcome... please post them to the mailing list for the enjoyment
and amusement of all!
Dan Blumenfeld
University of Pennsylvania
[blumen@wharton, dan@mc]
-----------------------------
End of SUN-Spots Digest
***********************