Sun-Spots-Request@RICE.EDU (William LeFebvre) (12/08/87)
SUN-SPOTS DIGEST Monday, 7 December 1987 Volume 5 : Issue 67
Today's Topics:
Re: Modifying buffer allocation (2)
Re: 3rd Party Disk Support
Re: Delinquent ttyp* terminals
Re: yp problem after server crash
NFS over Arpanet Solved
Public Domain c-kermit
System crashing in Common Lisp
Request For Summagraphics Digitizer Driver Software.
Just 4M Sun 3/50's?
Intercepting keyboard activity?
How to eroff from Sun onto LaserWriter Plus?
Wanted: TIFF --> Sun raster filter
Displaying MacPaint files on Sun?
----------------------------------------------------------------------
Date: Thu, 26 Nov 87 22:42:23 EST
From: hedrick@aramis.rutgers.edu (Charles Hedrick)
Subject: Re: Modifying buffer allocation (1)
A user asked about increasing the amount of memory used for buffers in a
file server. We have tried a couple of experiments. The default is to
use 10% of available memory (after the kernel takes its piece) for
buffers. I agree that if a machine is doing nothing but file serving, it
seems like you should use more of its memory for buffers. We do this by
patching the place in the kernel where the amount of space is computed.
But for most people, it is probably most convenient to do it using adb.
I'm reasonably sure you can just change the value of bufpages in your
vmunix:
cp /vmunix /vmunix.old ;keep a backup in case something goes wrong
adb -w /vmunix
bufpages?W NN
^D
The initial value in /vmunix will be zero. The code in the kernel
computes a value itself if it is zero, but if you set a nonzero value, it
uses what you set. NN can be gotten by looking at the value in your
current kernel while you are running (i.e. after the kernel has set up the
value), e.g.
adb -k /vmunix /dev/mem
bufpages/X
Note that the numbers will be in hex. If you prefer decimal, use
bufpages?W 0tNN
to change and
bufpages/D
to examine the current value in the running kernel.
The other relevant number is nbuf, but nbuf is set from bufpages, so it
looked to us like bufpages was the one to set. I suggest that you start
by doubling the current value. We have tried 10%, 20%, and 50%. 50% is
clearly too large. Bad Things start happening, like yp responses timing
out. 20% seems harmless. Whether it accomplishes anything or not is not
so clear. We once asked on this list whether anyone ever observed a
benefit by using more than 4MB on a file server (that is a pure file
server, once that does nothing other than that, and probably a few random
things such as yp). We got no responses. But it would seem like any
benefit it might give would have to be an increase in buffer memory. And
increasing bufpages gives that much more cheaply. At least up to a point.
Our experiment with 50% showed that a good thing can be carried too far...
------------------------------
Date: Sun, 29 Nov 87 18:48:49 EST
From: bzs@bu-cs.bu.edu (Barry Shein)
Subject: Re: Modifying buffer allocation (2)
On initialization (at boot) the system checks if the global 'nbuf' is
non-zero, if it is it uses that number instead of calculating based on
physical memory size. All you need to do is patch that value in /vmunix
and re-boot. See 'adb -w'.
-Barry Shein, Boston University
------------------------------
Date: Thu, 26 Nov 87 11:27:20 EST
From: umix!lokkur!scs@rutgers.edu (Steve Simmons)
Subject: Re: 3rd Party Disk Support
In SUN-SPOTS DIGEST V5, Issue 64 bzs@bu-cs.bu.edu (Barry Shein) writes
>Do these vendors have old volume contracts with competitors stipulating
>exclusion from selling to Sun customers, so they do it kind of sub-rosa?
>I dunno, it's really strange, are there any manufacturers on the list who
>might offer some insight? [[on why they can't help us with diag, etc ]]
I can't offer any facts, but here's some opinions.
First, Sun does attempt to keep 3rd party vendors at bay. There are some
good reasons for this and some bad reasons for this.
Sun goes to great lengths to "qualify" their vendors, making sure that
things will be as reliable as possible. You can argue with their
results, but you've got to admire the attempt. We had long talks with
them about the process and were quite impressed. BUT-- this
qualification is a long and painful process. Sun's not gonna go thru it
more than they have to, nor are they gonna tell you who failed. All I
can say is that for the big SMD drives, Fujitsu passed. Thus Sun
supports them.
Sun does not make hardly any money on 3rd party peripherals. That
includes disks, controllers, tape drives, and even the monitors. [An
aside to folks with B/W monitor problems -- a nameless engineer at Sun
once said that there was a period when NO-ONE had a monitor that met
Suns standards. Thus they shipped the one that came the closest. Lucky
for us, we didn't buy any about that time. And no, don't write me and
ask for details.] Even when they can get an incredible deal (say, half
price) from the vendor, any reasonably large company (like us) can get
nearly the same deal from the same vendor. So it's just not in Sun's
interest to spend huge amount of money and time qualifying 3rd-party
vendors.
In some cases Sun puts their own engineers to work with a 3rd party to
get an item that does exactly what Sun wants. Xylogics is a notable
example. When this happens, Sun wants their cut on the product.
Sometimes this comes in the form of an exclusive marketing arrangement.
When that happens, the vendors regretfully can't help you.
Sun is not in the business of cutting their own throats. So when an
un-qualified disk vendor (yes, there's at least one out there) wants to
put their disks on a Sun, Sun ain't about to tell you OR him how to do
it. Nor are they gonna tell you if the vendor failed qualification.
Their "best of a bad lot" choice is to be silent.
Now, some other opinions on 3rd-party vendors:
I average one unsoliticited 3rd-party contact a week. These people are
very anxious to do business with us, and the ones we talk with closely are
willing to supply things like device drivers, engineering support, etc.
They are much more co-operative with us than with, say, the Univ. of
Michigan, just down the road. Why? Because we re-sell more Suns in a
month than U of M buys in a year. Because we have our own engineers and
support staff -- when there's a problem or a change, they tell me and I
tell the field and tech staff. At U of M, every department with a Sun is
an individual entity and must be supported individually. We get about the
same discount that U of M gets, but we move ten times the volume (and are
going up). The end result: we get good service, U of M gets the pits. I
suspect the same situation pertains to any educational institution.
[[ Well, almost any institution. Rice usually seems to get decent
service! :-) --wnl ]]
Sorry to have blown on for so long, but I thought a word from the
corporate side was needed.
Steve Simmons
Schlumberger/Applicon (bigger than most countries)
Ann Arbor, MI.
....ihnp4!umich!dwon!lokkur!scs
Oh yeah -- these are my own opinions. The Schlumberger family doesn't
even know I exist.
------------------------------
Date: 27 Nov 87 05:20:18 GMT
From: Andrew D. Bowen <rutgers!cisunx.psu.edu!psuvax1!pitt!adbst@uunet.uu.net>
Subject: Re: Delinquent ttyp* terminals
I have noticed the same thing, and there are two fixes I can offer. The
first is a kludge, but is easy if you don't have alot of clients attached.
Just empty the file /etc/utmp. DON'T RM IT! Just delete all the lines
using your favorite editor, and save an empty file. Then logout and when
you login again, utmp will be updated.
Option 2 is a pain in the butt. Just open shelltools until you have
recaptured all the delinquents. SunOS will give you those ttyp*'s when it
is their turn to be used. Then explicitly close them.
I hope they fix this in SunOS-4..... Although, it doesn't seem to have
any ill effects on the system, other than annoying phantom users hanging
around.
Andy Bowen
Dept. of Electrical Engineering
University of Pittsburgh
------------------------------
Date: 29 Nov 87 04:34:43 GMT
From: leres@ucbarpa.berkeley.edu (Craig Leres)
Subject: Re: yp problem after server crash
The main problem here is a network bug; under every version of Sun OS I've
seen (we run 3.3), rpc broadcasts go to broadcast UNLESS you have
installed default route in which case they go to the gateway the default
route points to.
When your yp server becomes indisposed for a few minutes, the ypbind on
your client workstation gives up it, forgets who the yp server used to be
and tries to aquire a new one. Unfortunately, if you have a default route
and it points to a machine that is not also the yp server, you are dead in
the water.
A workaround is to point the default route on your clients at your yp
server and point the default route on the yp server at your gateway. This
has the undesirable side effect that off-site out-bound packets take an
extra hop.
But since it's VERY unlikely that one would change yp servers without
rebooting clients (and since I have source) I modified ypbind to NEVER
throw away the yp server. Appended is a short context diff to etc/ypbind.c
(1.1 86/09/24) (which is either 3.2 or 3.3).
Craig
------
--- ypbind.c Fri Jul 17 18:37:37 1987
***************
*** 650,658 ****
--- 652,671 ----
}
if ((clnt_stat = (enum clnt_stat) clnt_call(pdom->ping_clnt,
YPPROC_NULL, xdr_void, 0, xdr_void, 0, timeout)) != RPC_SUCCESS) {
+ #ifdef notdef
pdom->dom_boundp = FALSE;
clnt_destroy(pdom->ping_clnt);
pdom->ping_clnt = (CLIENT *)NULL;
+ #else
+ {
+ char outstring[YPMAXDOMAIN + 256];
+
+ (void) sprintf(outstring,
+ "yp: server not responding for domain \"%s\"; still pinging",
+ pdom->dom_name);
+ writeit(outstring);
+ }
+ #endif
}
}
------------------------------
Date: Sat, 28 Nov 87 21:48:58 PST
From: ho@tis-w.arpa (Hilarie K. Orman)
Subject: NFS over Arpanet Solved
We had a difficult time getting NFS to work over the Arpanet and finally
traced the problem to an addressing problem generic to all(?) UDP-based
services. We had to use "route" at the server site to translate the
client machine's local network address to its internet address. With this
amendment, we got NFS working immediately, and find it a great boon. I
gather that sites running the exterior gateway protocol (EGP) do not see
the problem.
We ran into severe problems with Sun in tracking down the problem. The
engineering group is "sensitive" about NFS over low-speed networks,
because they feel that using TCP instead of UDP would result in improved
performance. We were advised to register an official request for software
enhancement whenever we asked for help. Because of this issue lurking in
the background, it was almost impossible to get anyone to pay attention to
our specific problem, which was that the reply packet from a "mount"
request was being lost. However, once we guessed what the problem was and
provided corroborating evidence, I was gratified that we got a response
and workaround almost instantaneously.
The feeling I got during the month that this problem was pending was like
trying to get a Rolls Royce serviced at a VW dealership. For a company
with the motto "The Network IS the Computer", the level of understanding
of networking is quite low. About all I can say is that they did get it
back on the road without bending the grille.
------------------------------
Date: Fri, 27 Nov 87 19:36:57 CST
From: texsun!dal02!dal01!twm@sun.com (Taylor Mohrle)
Subject: Public Domain c-kermit
The following is public domain (as far as I know) for the Kermit protocol
and is running on our Sun 3/260 with no problems. Since your users have
asked for it and we have found many situations in which it was necessary
please consider placing it on your Archive-Server. I know that this
version will run with the popular PC package Procomm (TM) by DataStorm
Technologies.
Taylor Mohrle
Network Administrator
[[ The source file has been placed in the archives under the name
"sun-source/ckermit.c". It can be retrieved via anonymous FTP from the
host "titan.rice.edu" or via the archive server. For more information
about the archive server, send a mail message containing the word "help"
to the address "archive-server@rice.edu". --wnl ]]
------------------------------
Date: 25 Nov 87 23:13:25 GMT
From: hedrick@aramis.rutgers.edu (Charles Hedrick)
Subject: System crashing in Common Lisp
I'm interested to know whether anyone is seeing system crashes due to
corrupted page tables. We have a funny enough situation that I'm
reluctant to report this as a bug to Sun. We recently installed a Ciprico
Rimfire disk controller on a 3/280. The disk controller seems to work
fine. We do see the sorts of performance improvements I had hoped for (at
least a factor of 2 improvement in the maximum rates we see using vmstat
in normal operation, up to a factor of 3 when I contrive test situations).
However we now find that the system is crashing whenever one of our users
runs Franz Common Lisp. I have no particular reason to believe that this
has anything to do with the new controller. But it did work a few weeks
ago, and that's all I can think of that has been changed. Ciprico
believes it isn't their problem. I'm inclined to agree. We can tell from
postmortems that neither the process nor the shared text segment has ever
been swapped, so it's hard to see how the disk could be involved. When we
look at the dump, I find that the page table for the process involved has
the following pattern:
- the first 0x200 bytes are mostly zero, with some apparently
valid entries.
- from 0x200 to the end of the text portion of the page table,
there is executable code. Note page table entries pointing
to code, but actual 68000 machine instructions.
- the section of the page table for the data area looks fine.
The pattern of mixed zero and valid entries is very hard to understand,
and the code is even wierder. The exact same pattern has shown up in 4
different dumps, although which words are zero is not the same, and the
particular code that is present after offset 0x200 is not the same. It is
clear that whatever code is supposed to set up the page table is being
called, or the valid entries wouldn't be there. I'm inclined to suspect
that maybe the cache (a feature present only on the 280) is not being
flushed at some point, so that the data ends up going to the wrong place
for some words, depending upon patterns of previous references. Based on
this I am going to try inserting cache flushes at a couple of
likely-looking places in the paging code. If that doesn't work, then I
have to consider going back to the Xylogics controller. The purpose of
this message is to see whether anyone else has seen similar problems. If
so, this would make us more likely to say that the problem isn't with the
controller, and treat it as a generic kernel bug.
------------------------------
Date: 25 Nov 87 17:35:47 GMT
From: umt!morarre@ucbvax.berkeley.edu (Tom Morarre)
Subject: Request For Summagraphics Digitizer Driver Software.
Howdy,
One of my users sent me with this querry. If anyone has a driver for the
Summagraphics Microgrid II that will work on a Sun 3/110, please let us
know. tam...
______________________________
Tom,
I've got this Sun 3/110 and a summagraphics microgrid II digitizing table
(42" x 60"). I want to use the table to digitize contour maps and simple
sorts of geologic maps and diagrams along with occassional seismic traces,
etc. I need a program to interface the two pieces of equipment. Before
reinventing the wheel, I thought I'd see if you knew where I might acquire
existing code for this task.
Thanks,
Steve
--
Tom Morarre
Manager of User Services
University of Montana
...!ucdavis!umt!morarre
------------------------------
Date: Sun, 29 Nov 87 12:51 EST
From: LYMAN@IASSNS.BITNET
Subject: Just 4M Sun 3/50's?
We have about 8 Sun 3/50's with, of course, the standard 4M of memory.
This is seen more and more as a liability. Short of trade ins, is there
any way now or plans in the future to upgrade the memory on a 3/50 to 8M
or 12M?
Lyman Hurd
Inst. for Advanced Study
Princeton, NJ
------------------------------
Date: Mon, 30 Nov 87 16:32:31 CST
From: ables@mcc.com (King Ables)
Subject: Intercepting keyboard activity?
Someone here is looking for a way to intercept or monitor keyboard
activity (i.e. log all they keystrokes) on a Sun regardless of what
activity is happening (suntools independent of which window one is in,
Interleaf, Frame, etc.).
We thought of modifying the tty drivers but don't really like that (for
obvious reasons). I was also suggested a program could be written to
monitor /dev/kbd and grab traffic, log it, and then pass it on.
We've thought of all sorts of contorted hardware schemes, too, but would
really like to avoid that sort of solution.
Has anyone actually DONE anything like this? If so, how did you do it and
what would be the chances of my obtaining it? If not, does anyone have
any suggestions they'd just LOVE to pass along? This is one of those
things that sort of needs to get done, but we just don't have the
resources within our group to devote a lot of time to it right now. I'd
really love to find out that someone has already invented this wheel!
Adv(thanks)ance
-king
ARPA: ables@mcc.com
UUCP: {gatech,ihnp4,nbires,seismo,ucb-vax}!ut-sally!im4u!milano!mcc-pp!ables
------------------------------
Date: 26 Nov 87 01:55:54 GMT
From: masha@june.cs.washington.edu (Marianne Mueller)
Subject: How to eroff from Sun onto LaserWriter Plus?
Help! We're using Elan Computer Group's "eroff" to print files from a Sun
3/50 to an Apple Laser Writer Plus.
The files in question are generic troff files, that use the command
pic file | tbl | eqn | troff -ms
When we try
pic -D file | eqn | tbl | eroff -ms
(note: eroff wants eqn before tbl, according to the Elan manual)
we only ever get the last two pages of output, no matter how big the
output file So, we print files by (groan) executing
pic -D file | eqn | tbl | eroff -ms -o1
pic -D file | eqn | tbl | eroff -ms -o2
pic -D file | eqn | tbl | eroff -ms -o3
...
That is, one eroff for each page!!!!
If anyone else has this problem, or if you think you know what we're doing
wrong, we'd love to hear....
Send mail to escd!es56!marianne@decwrl.dec.com
Thanks...any hints greatly appreciated.
Marianne
------------------------------
Date: 30 November 1987 1115-PST (Monday)
From: lim@nprdc.arpa (Bill Lim)
Subject: Wanted: TIFF --> Sun raster filter
Does anyone out there have or know of a TIFF to Sun raster filter? If so
I'd like to hear from you. While I'm at it, is there a PCPAINT to Sun
raster filter too?
Bill Lim
lim@nprdc.arpa
ihnp4 \
akgua \
decvax >---- !sdcsvax!sdics!nprdc
dcdwest /
ucbvax /
(619)225-6434
------------------------------
Date: Mon 30 Nov 87 16:34:46-EST
From: Tod Pike <PIKE@tl-20b.arpa>
Subject: Displaying MacPaint files on Sun?
I am looking for a program to display a file in Apple MacPaint format on a
Sun system. If anyone has such a beast, or at least knows the format of a
MacPaint file, I'd appreciate a message. Thanks,
Tod Pike
Pike@Tartan.Arpa
------------------------------
End of SUN-Spots Digest
***********************