Sun-Spots Digest, v6n277
William LeFebvre
Sun-Spots-Request at Rice.edu
Mon Oct 31 07:02:53 AEST 1988
SUN-SPOTS DIGEST Sunday, 30 October 1988 Volume 6 : Issue 277
Today's Topics:
Mail problems at ukc.ac.uk
Re: Memory for a Sun 3/50 (2)
Re: PosScript printers for Suns? (networking printers)
Re: Shared memory "zombies"
Re: Kernel paramters for streams
Re: LaTeX and TeX environment on Suns
viewtool
DELNI collisions (was: SLOW Boot on diskless Suns)
4.0 Sun3 assembler vs. New S
Cure for the Summertime Blues?
experiences with multiple file servers ?
How to adjust tset to setup vt100 emulation?
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server at rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Sun, 30 Oct 88 14:20:02 CST
From: William LeFebvre <phil at Rice.edu>
Subject: Mail problems at ukc.ac.uk
The host ukc.ac.uk seems to be having some mail problems. And it likes to
send failed mail messages about a digest to *everyone* who has a message
in the digest (all the addresses in all the "From:" lines throughout the
entire body---and it doesn't even do a very good job of building the
addresses). Everyone please note: (1) I am aware of the problem, having
received quite a few of these messages myself, (2) I am *NOT* the source
of the problem (it isn't my fault), (3) I can do nothing about the
problem, (4) sending copies of this particular failed mail message to the
request address is appreciated but unnecessary and is even getting to be a
hindrance, (5) someone has already complained to ukc.ac.uk and hopefully
the problem will be cleared up soon, (6) this is happening to other
digests (such as TeXHax) as well.
William LeFebvre
------------------------------
Date: Fri, 21 Oct 88 09:24:25 PDT
From: frame!merlin!sll at sun.com (Suzann Larsen)
Subject: Re: Memory for a Sun 3/50 (1)
> I spoke with a company in Cambridge, MA recently, that claims to
> have upgrade memory for Sun-3/50s.(I will believe it when I see it.)
We saw it, we have it, we believe it, we love it! I don't know about the
Cambridge company, but we have been a beta site for add on memory for
Sun-3/50s from Helios and have been using it with no problems for nearly a
month. We have a 4MB and an 8MB add on, giving two very happy users an
8MB 3/50 and a 12MB 3/50. We were sworn to silence during beta, but now
they've recently made an official announcement.
I was told 4MB would list at $2500 and 8MB at $4750, but of course this is
not "official". The local rep I have been dealing with is Dave McWalters,
408-730-2121. If you are interested, I suggest you jump on it quickly,
they are still ramping up production and only have limited quantities
available.
Suzann Larsen Frame Technology
System Administration 2911 Zanker Road, San Jose CA 951324
------------------------------
Date: Mon, 24 Oct 88 14:20:21 PDT
From: Jim Frew <frew%huevos at hub.ucsb.edu>
Subject: Re: Memory for a Sun 3/50 (2)
I just got a teaser card in the mail from Helios Systems advertising
add-in memory for Sun-3/50s. A phone call produced the following info:
The memory is available in the following sizes:
MB Univ. of Calif. price (real world == $ ?)
-- ------
4 $ 2200
8 $ 4250
[[ Rob Liebschutz (rob at presto.ig.com) sent in a message that said "real
world" prices were 4 meg for $2500 and 8 meg for $4750, and that price
breaks were available for quantities of 10 or more. My thanks to him and
others who have sent in similar information. --wnl ]]
Each card is a daughter board that sits on top of the 3/50 mother board.
The connecting cable must be SOLDERED (!) to the mother board. Since this
is a non-trivial installation procedure, you can:
-- send the motherboard to Helios and have them install it, for an
additional $200 (UC price)
-- have them train one of your people to do the installation ($ ?)
-- have them send someone to your site to do the installation ($ ?)
The teaser card advertises "immediate delivery"...
For more info try:
Helios Systems
1996 Lundy Ave
San Jose, CA 95131
408 432 0292
NOTE: I have NO connection with Helios, other than being a satisfied
customer.
Our Clearpoint rep has told me that they are working on a similar upgrade,
but I haven't seen an announcement yet.
James Frew CSL/CRSEO, UCSB, Santa Barbara, CA 93106 +1 805 961 8413
frew at hub.ucsb.EDU ucbvax!ucsbcsl!frew frew at ucsbuxa.BITNET
------------------------------
Date: Mon, 24 Oct 88 10:53:28 EDT
From: ted at braggvax.arpa
Subject: Re: PosScript printers for Suns? (networking printers)
In #268 there's some discussion between wnl and Stephen Daniel about
networking postscript printers. I've just come across an interesting item
in my mail from QMS (who now own Imagen, by the by). They have a box
called QMS PrintLink that sits on your Ethernet as an IP host and lets you
FTP print jobs to it. It spools them and prints them on an attached
serial or parallel printer. So you should be able to network just about
any kind of printer...
[[ FTP?!? FTP?!? Why FTP? Seems like overkill to me. --wnl ]]
Their Atlanta number is (404) 751-0043
Ted Nolan
ted at braggvax.arpa (192.5.92.100 these days)
Disclaimer:
I have no connection with QMS, haven't called the above number, and have
never even seen the thing.
------------------------------
Date: 20 Oct 88 08:06:53 GMT
From: rb at ist.CO.UK (Bob Bishop)
Subject: Re: Shared memory "zombies"
> Has anyone using System V shared memory found a clean way of dealing with
> the potential "zombie" shared memory segments?
My best shot at this is: the process creating the shm segment forks off a
child which sits on a timer, doing a shmctl(IPC_STAT) periodically to find
out how many processes have the segment attached. When the count drops to
1, it does a shmctl(IPC_RMID) and exits. This keeps the shared segment
around as long as any process other than its "minder" process is attached,
and other processes can attach and detach freely.
There is of course a race condition to be avoided: "minder"
finds shm_nattch == 1, another process attaches, "minder" does
shmctl(IPC_RMID) ...
------------------------------
Date: Mon, 24 Oct 88 10:09:49 PDT
From: stevo at judy.jpl.nasa.gov (Steve Groom)
Subject: Re: Kernel paramters for streams
>From: ehrlich at shire.cs.psu.edu (Dan Ehrlich)
>...
>It appears that not only is the number of streams NOT dependent on
>MAXUSERS, number of pseudo-ttys, or anything else. In order to get around
>the current problem we just upped NSTREAM to 48, until we can figure out
>what a reasonable formula for it should be.
>
>Has anyone else seen this happen? What if anything was done to fix it?
>Can anyone at Sun explain why NSTREAM is fixed at 32?
This problem started for us the day after we upgraded to 4.0. Like Dan, I
went into /usr/sys/sun4/HOSTNAME/param.c and changed NSTREAMS, I went to
64. I rebuilt the kernel using the fixed param.c and the problem went
away.
(for the record: this was originally on a 4/280, but applies to all
Sun2's, 3's, and 4's.)
Later, when speaking to a tech person at Sun about another matter, I
mentioned the streams problem. He said that in 4.0, there are a number of
streams data structures that are statically sized and do not depend in
MAXUSERS, but will be dynamically allocated in later releases. NSTREAMS
is only one of them.
He suggested that I check and modify several parameters in param.c (in
addition to NSTREAMS). These are the number of streams data blocks
(dblks) of different sizes (bytes) that the kernel allocates at boot-time.
#define NBLK4096 0
#define NBLK2048 32
#define NBLK1024 12
#define NBLK512 8
#define NBLK256 32
#define NBLK128 96
#define NBLK64 240
#define NBLK16 400
#define NBLK4 128
After a machine has been up for a while and has been heavily loaded, do a
'netstat -m'. The output describes network memory allocation information
and streams information. The streams information shows the current and
the maximum (since boot, not max avail) number of streams allocated, and
the number of allocation failures. Below that is allocation information
for dblks. The idea in tuning these parameters is to reduce the number of
allocation failures to 0.
How to do it? Brute force. The method suggested was to increase all of
the NBLXx parameters by a large amount (say, triple or quadruple each of
them, and raise NBLK4096 to about 16). Then load the machine and watch
for more allocation failures. Maybe let it run for a day or two. If you
see a lot of failures, increase the corresponding parameter(s) and repeat.
When things look good (few or no failures), start trimming them back down.
Use the high-water marks under the 'maximum' column as a guide, setting
the parameter to something like 20% over the maximum.
(BTW, I'll say it here in case you haven't figured it out -- you need to
make and install a new kernel, and reboot each time you change param.c.)
I am not certain of the overhead associated with these parameters - in
other words, what it costs in terms of kernel memory usage when you
increase them. NBLK4 refers to 4-byte blocks and so on, so if you add
them all up you'll find its on the order of 100K - not too much to ask on
server. Even tripling that probably wouldn't hurt. But it is important
to realize that you should be sure to go back and trim out the excess.
Never-used buffer space doesn't buy you anything in performance, and it
does cost something in terms of wasted memory. So don't skip the
trim-down step, even though its not that urgent.
This appears to have helped performance on our machines, especially on our
I/O-intensive Sun2. Precise measurements are difficult, because we are
talking about overall system performance, not just raw speed or throughput
or somesuch. But as I said, it appears to have helped. Of particular
help was the addition of a few NBLK4096's. Why the default on that one is
0 I don't know.
Many thanks to the extremely helpful tech person at Sun.
-steve
Steve Groom, Jet Propulsion Laboratory, Pasadena, CA 91109
Internet: stevo at elroy.jpl.nasa.gov UUCP: {ames,cit-vax}!elroy!stevo
Disclaimer: (thick German accent) "I know noothingg! Noothingg!"
------------------------------
Date: Mon, 24 Oct 88 12:04:51 pdt
From: rusty at cartan.berkeley.edu
Subject: Re: LaTeX and TeX environment on Suns
> From: bonham at ucalgary.ca (Michael Bonham)
>...
> 1) Is there an undump for SunOS 4.0? Where is it or how do I build one?
>...
In my opinion (and other's) you're better off using the virtex scheme of
loading the .fmt files IF you use the c version of tex. You can get the c
version of tex, metafont, et. al. via ftp to ics.uci.edu. "get" the file
web2c.tar (and anything else that looks obvious). This is so much faster
than the pascal version that the time loading the .fmt files is trivial.
An additional advantage is that the undumped versions are huge (take up a
lot of disk space) whereas the virtex/.fmt files aren't. Another
advantage is the the web2c package includes a change file to make a
"gargantuan" tex, and it doesn't use any more disk space. With the
gargantuan tex you'll probably never get the "tex capacity exceeded"
message unless there's a bug in one of your macros.
------------------------------
Date: Mon, 24 Oct 88 11:53:02 EDT
From: rainbow at sbcs.sunysb.edu
Subject: viewtool
Two friends and myself have developed a SunView program that can be used
to quickly prototype SunView user interfaces (A more complete discribtion
of viewtool is at the bottom of this message). This tool is called
viewtool and is currently being beta tested. If anyone out there in
"Netland" would like to join the growing number of viewtool beta testers,
or would just like a copy of the sources to check out, you can do the
following:
send email to:
UUCP: {allegra, philabs, pyramid, research}!sbcs!rainbow
CSnet: rainbow at suny-sb
Bitnet: in%"rainbow at sbcs.sunysb.edu"
Arpanet: rainbow at sbcs.sunysb.edu
with the Subject: viewtool source request
or viewtool can be ftp'ed from sbcs.sunysb.edu (129.49.89.3). (ALSO,
touchup (bitmap editor) and 8to1 (sun rasterfile color to mono converter)
are available for anonymous ftp from suny)
When the release version of viewtool is complete, it will be posted to the
net.
min
____________________
Viewtool is a window and mouse-based user interface tool for generating
SunView application programs.
Viewtool provides a convenient and powerful user interface for SunView
programmers to write their application programs' user interface part, they
do not have to go through the tedious job of creating windows,
setting window parameters etc. but are provided a visual interface to
create frames, subwindows and panel_items, resize, copy and move them
dynamically. Finally, viewtool generates the "C" code with the SunView
window-specification calls for you, what you see is what you get.
Viewtool enable the user to quickly create frames, panels etc. dynamicly.
While the user is on viewtool they can "move", "copy" and "tidy" panel
items. Once you have built the correct SunView user interface, you can
have viewtool generate the "C" code that is required to build the current
interface. This "C" code then can be incorpated in to you only programs.
------------------------------
Date: Mon, 24 Oct 88 14:54:30 edt
From: eplunix!das at harvard.harvard.edu (David Steffens)
Subject: DELNI collisions (was: SLOW Boot on diskless Suns)
> Appearently there is enough shared logic in the DELNI that trying to
> rapidly pump large amounts of data between two ports results in a large
> number of 'collisions' being reported. (Can anyone confirm/deny this?)
I'm no expert, but this doesn't sound right. We had a similar problem and
found the _real_ cause of these "pseudo-collisions" was Ethernet version
mismatches. We thought we could just insert a DELNI between an old
Interlan board and its transceiver. No way since that hardware was
version 1 and the DELNI is (sort-of) version 2. We saw a _lot_ of
collisions when sending thru the Interlan, e.g. average of 1.5 collisions
per packet sent! Attaching the DELNI to the backbone with its own
transceiver and re-connecting the old hardware fixed that. Now I can send
gobs of packets from one port of the DELNI to the other without seeing a
_single_ collision when our net is lightly loaded.
{harvard,mit-eddie,think}!eplunix!das David Allan Steffens
243 Charles St., Boston, MA 02114 Eaton-Peabody Laboratory
(617) 573-3748 Mass. Eye & Ear Infirmary
------------------------------
Date: Mon, 24 Oct 88 10:15:53 EDT
From: mcintosh at flash.bellcore.com (Allen Mcintosh)
Subject: 4.0 Sun3 assembler vs. New S
I ran into this one also. You can bypass it by moving the definition of
catchfpe() to the front of the file. I suspect that this is an obscure
bug in the SDI algorithm in the assembler. I have a relatively small file
that re-creates the problem, if anyone out there is interested.
Allen McIntosh
mcintosh at flash.bellcore.com
------------------------------
Date: Mon, 24 Oct 88 12:59:02 BST
From: Paul Leyland <pcl%robots.oxford.ac.uk at nss.cs.ucl.ac.uk>
Subject: Cure for the Summertime Blues?
The algorithm for detecting the end of summertime in the UK for SunOS is
bugridden this year. We all altered our clocks this weekend. When I came
in this morning, the machines were still on BST. 'Sfunny, but it got it
right in the spring. Does *anyone* understand how BST/GMT is decided?
Paul Leyland (JANET: pcl at uk.ac.ox.robots)
(UUCP: ...!mcvax!ukc!ox-rob!pcl)
------------------------------
Date: Mon, 24 Oct 88 08:02 EDT
From: davis%blue at sdr.slb.com
Subject: experiences with multiple file servers ?
Organization: Schlumberger Cambridge Research
Snail: PO Box 153, Cambridge CB3 0HG, England
Phone: [+44] (0) 223 325282
We're in the process of trying to install our new 4/260 file server and
I'd appreciate some pointers on other folks experiences. The heart of our
problem is that it really looks as if we're going to move from a system
with a single point of failure (the exiting server) to one with two:
here's the gen:
existing: 3/180 server with 14 clients (3/50's, 3/110's)
with 2 375MB disks and 1 575MB disk
planned: 4/260 server with 14 clients (3/50's, 4/110's)
with 2 892MB disks
3/180 server with 7 or 8 clients (3/50's, 3/110's)
with 2 375MB disks and 1 575MB disk
Problems:
/home : if we put all user home directories on one disk attached
to the 4/260, the whole system is `down' if this server
goes down.
/export/exec/sun3: there seems little point in duplicating the
binaries for the Sun 3's, so the plan is to "mount" the
/usr dir of the old server as /export/exec/sun3 on the new
one, albeit done directly by the clients (you can't do a
third party mount). This gets us into a stupid
cross-thread of file-serving activities.
It looks to me as if we might be trying to do something highly
inappropriate here: comments or pointers anyone ? What I'd really like to
go for is all home dir's on one disk (or at least, one server), and as
little other cross-threaded file serving as possible. It doesn't look
straightforward, but maybe I'm thinking about it TOO hard.
thanks in advance,
Paul Davis
Internet: davis%blue at sdr.slb.com
------------------------------
Date: Mon, 24 Oct 88 09:02:52 CDT
From: AARON KONSTAM <79343382 at TRINITY.BITNET>
Subject: How to adjust tset to setup vt100 emulation?
I wonder if someone could help with the following problem. I can set a
tset containing line in .login so that all dialin access causes the Sun 3
to enter Vt100 emulation but I have been to construct a command that would
force the Sun to be a vt100 terminal if the user was on a dialin terminal
or the user wasn't on the console. This should be possible but I can't
male SunOS 3.5 accept the @ sign that the documentation says means not.
You can write me directly.
Aaron Konstam
Trinity University
79343382 at trinity.bitnet
P.S. By the way ASCII to EBCDIC to ASCII turns right and left Brackets to
U and E and converts the C OR symbol to right bracket. I couldn't type
those directly into this message for that reason. This as one might
imagine plays havoc with C source and shell programs sent by electronic
mail.
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list