Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/08/88)
SUN-SPOTS DIGEST Sunday, 7 August 1988 Volume 6 : Issue 172
Today's Topics:
Re: yp provided by Sun, DEC and who else
Re: Revenge of the 68881
Re: tcsh on a Sun-4
Re: Problem Connecting a Printer to a Sun
Garbage collecting malloc
Sun-4 & DBX
SunOS 4.0
More about X11 adjacent to suntools on Sun 3/60 (X11 in color group)
Problems: ypserv & nameserver on SUNOS 3.5
Problems with groups under PC-NFS
Need info on RFC's
SUN-2 disks?
Photographic Output Devices?
Send contributions to: sun-spots@rice.edu
Send subscription add/delete requests to: sun-spots-request@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@rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Fri, 29 Jul 88 17:45:54 edt
From: oxtrap!rich@umix.cc.umich.edu (K. Richard Magill)
Subject: Re: yp provided by Sun, DEC and who else
Reference: v6n151
>From: mkhaw@teknowledge-vaxc.arpa (Mike Khaw)
>
>Aside from SunOS and Ultrix, what other vendors supply and support yp on
>their Unix boxes and how up to date is their NFS/yp compared to SunOS?
Sequent provides NFS+yp but without the locking daemons. (we use it).
Mips offers an NFS+yp but I haven't used it.
rich.
------------------------------
Date: Fri, 29 Jul 88 22:46:25 EDT
From: Jim Barby <jabarby@watvlsi.waterloo.edu>
Subject: Re: Revenge of the 68881
Reference: v6n152
In v6152 Dave Bernholdt was surprised about the high overhead -fswitch
has. I did some bench marking a few weeks back and sent off a request to
hotline@sun.com to explain the high overhead indicated in the bench marks
below. There reply and looking at the assembler pointed out that both
-fsoft and -fswitch do a subroutine branch for each floating point
operation, while -f68881 and -ffpa use inline code (or atleast if it is
f77). Besides the subroutine branch -fswitch has to execute some code to
determine the fastest floating point hardware available on the host.
I had been putting off posting the results because I figured very few
people would be interested. It appears I was wrong, so the following are
the results. The test program was designed to be very floating point
intensive with little in the way of integer operations.
++++++++bench mark test of floating point operations+++++++++++++++++++
Interesting results of a simple floating point test on different Sun
workstations. The "-O" compile flag appears to have a significant impact
on the cpu times. In fact unless one takes precautions, the -O option has
too large of impact on the cpu times because it throws most of the
floating point operations away (as pointed out by Paul Layman). Therefore
the test program was modified to use the values of "add,sub,mul,div"
outside the loop, to prevent the optimizer from throwing them away.
The numbers also indicate that the new MC68881 on a slower 3/50 is just as
fast as the older MC68881 (ie old mask with bugs that are corrected in
software) on a faster 3/160. This is seen my comparing the -f68881 cpu
times for "vlach" a 3/50 with new version of MC68881, "sun1" a 3/160 with
old version of MC68881 and "sun2" a 3/160 with new version of MC68881.
The conclusion of this is that SUN should be required to upgrade the buggy
old version of the MC68881 for workstations that have been under
continuous hardware service contract.
It should be pointed out that during the test without the "-O" flag, sun2
was very heavily loaded which increased its cpu times significantly.
========ratfor test program============================================
define N 10000000
double precision data(2), add, sub, mul, div
integer i
data(2) = 1
do i=2,N {
data(1) = data(2)
data(2) = i
add = data(2) + data(1)
sub = data(2) - data(1)
mul = data(2) * data(1)
div = data(2) / data(1)
}
write(0,*) add, sub, mul, div
stop
end
========hardware configuration=========================================
node name short name equipment
---------------+---------------+------------------------------
watvlach vlach older 3/50 with new MC68881
vlsisun1 sun1 older 3/160 with old MC68881
vlsisun2 sun2 3/160 with new MC68881 and FPA
vlsisun3 sun3 3/260 with MC68881
========test results with and without -O compile flag==================
cpu cpu times in minutes without using -O
name -fsoft -f68881 -ffpa -fswitch
-------+-------+-------+-------+--------
vlach 56.0 14.0 ---- 20.1
sun1 52.6 10.1 ---- 20.8
sun2 52.8 12.2 5.1 10.2
sun3 29.4 10.3 ---- 13.5
cpu cpu times in minutes using -O
before extra write statement to
prevent FLOPs being thrown away
name -fsoft -f68881 -ffpa -fswitch
-------+-------+-------+-------+--------
vlach 3.5 2.2 ---- 3.1
sun1 3.1 2.3 ---- 3.1
sun2 3.1 1.8 0.8 1.3
sun3 1.9 1.6 ---- 2.0
cpu cpu times in minutes using -O
name -fsoft -f68881 -ffpa -fswitch
-------+-------+-------+-------+--------
vlach 56.7 14.2 ---- 21.3
sun1 53.3 15.4 ---- 22.3
sun2 53.4 12.5 2.0 10.8
sun3 29.8 10.4 ---- 14.0
------------------------------
Date: 30 Jul 88 22:09:23 GMT
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Subject: Re: tcsh on a Sun-4
Reference: v6n154
Somebody reported that he couldn't get tcsh to work under 4.0 on a Sun 4.
He doesn't say what went wrong, nor have I looked at the code he mentions.
But I can tell you one thing that would eventually show up if you tried to
do such a thing. The program would tend to coredump. The problem turns
out to be documented. Any program that uses vfork on a Sun 4 under 4.0
and is compiled with global optimization on (the default for -O on a 4)
must include <vfork.h>. This supplies a #pragma that makes the compiler
do the right thing for vfork. It's quite reasonable that a globally
optimizing compiler would get confused by vfork. As a comparison Pyramid
says it is dangerous to use global optimization on their compiler for
anything that uses fork or longjmp (though it seems to work in all the
cases I have tried). On the other hand, some of us are less than thrilled
about having to search every program for vfork and modifying the source.
------------------------------
Date: Fri, 29 Jul 88 23:52:27 CDT
From: Jacob Gore <gore@eecs.nwu.edu>
Subject: Re: Problem Connecting a Printer to a Sun
I think you may be bit by your parity setting. Either your printer, or
your host, or both, may not realize that an XOFF with a high bit set
(10010001) is still XOFF. Try telling your printer and your host to use
even parity or "space" parity -- you want that leftmost bit to be zero.
Jacob Gore Gore@EECS.NWU.Edu
Northwestern Univ., EECS Dept. {oddjob,gargoyle,att}!nucsrl!gore
------------------------------
Date: Fri, 29 Jul 88 18:58:36 CDT
From: Hans Boehm <boehm@Rice.edu>
Subject: Garbage collecting malloc
The previously posted garbage collecting storage allocator has just been
updated. It is still available as gc.shar in the sun-source archive. It
grew to 68K bytes. The most significant change is Sun 4 support (thanks
to Mark Weiser).
If most objects are explictly freed, or if the ratio of available to
accessible memory is very high, the allocator frequently outperforms the
Sun 3.2 allocator by a large margin. Those people who have been
complaining about Sun's allocator (and don't need realloc) may want to try
it.
Hans-J. Boehm
boehm@rice.edu
------------------------------
Date: Fri, 29 Jul 88 15:03:16 CDT
From: Scott Guthery <spar!ascway!guthery@decwrl.dec.com>
Subject: Sun-4 & DBX
I've got a Sun 4/110 as a diskless node on a Sun 4/260 both running SunOS
4.0. I'm running a shelltool, a perftool and a dbxtool in Sunview. In
dbxtool I'm debugging a 2.8MB plain vanilla C program. It takes *** 45
SECONDS *** to set a breakpoint in this program. Cpu, interrupt, context
switching, and packet all peak during this time but all the other perf
measures stay at zero. Anybody have any idea why it takes 300 million
instructions to set a trap? I know it's RISC but com'on.
Cheers, Scott
P.S. Has anyone else noticed that dbx sometimes doesn't see the local (%l)
registers when debugging a leaf routine?
------------------------------
Date: Fri, 29 Jul 88 16:25 EST
From: 91ERM@vax.cc.williams.edu
Subject: SunOS 4.0
Ignoring the fact that the new suninstall is more or less three steps back
from the old setup, and the documentation went with it, here's a word of
advice for any yet to try 4.0: fill out the screens in top-to-bottom
order. This is what sun recommends, though I didn't see it anywhere in
the docs. For some reason, it seems important.
Give me setup, it worked and did so well.
Evan R. Moore
Williams College Computer Center
(A frustrated 4.0 installer ...)
------------------------------
Date: Fri, 29 Jul 88 18:13:30 EDT
From: klm@cme-durer.arpa (Ken Manheimer)
Subject: More about X11 adjacent to suntools on Sun 3/60 (X11 in color group)
[This is a yet simpler and tidier than what i discovered yesterday.]
I was recently recruited to help someone set up an environment for some X
clients on their system, a sun 3/60. I was given an excerpt from a may
issue of sun-spots that describes how to get X11 going on the monotone
plane of the framebuffer (/dev/bgtwo1), and after some fiddling around i
found a way to get X going on cgfour0 (the color plane group) while
suntools is running adjacently on bgtwo1. There is a slight bit of
finagling that must be done (essentially moving the mouse around) to get
this to work, which probably explains why the fact that it *does* work at
all is a bit obscure...
1. Invoke suntools *on bwtwo1* by entering (from the console):
'suntools -overlay_only -toggle_enable'
2. This second step is slightly tricky. We will init (xinit) X on
the color plane group and, on the same command line, start
adjacentscreens after a slight delay:
'alias xin xinit -- Xsun -dev /dev/cgfour0'
'xin & sleep 4; adjacentscreens -c /dev/fb -l /dev/cgfour0'
(I use the alias to fit all these commands on a single line for
illustration purposes only. You can use the expansion directly, eg
for a menu entry.)
3. After about five seconds move the mouse *far* to the left side of
the screen. It won't appear to move until you get far enough over
(and adjacentscreens has started) to make the transition to the
leftwards screen. (Until you cross this threshold the X mouse will
not appear to be moving - never mind that, keep moving.) Once you
cross the threshold you'll find yourself in the X environment, and
if you move back to the right you'll be back in the suntools
environment, but the screen there will need to be refreshed - it
will be all white, except for the boundaries of any windows you may
have crossed (and hence flashed their borders).
What seems to be happening is that the initial image of the X window
environment *in cgfour0* is superimposed over the bwtwo1 plane, though the
mouse and keyboard are still attached to the suntools in bwtwo1. In fact,
if you can cause a suntools redisplay without seeing what you're doing
then you may then be able to see what happening without transiting over to
the X environment. However, sliding the mouse over to the actual X
environment wil straighten almost everything out anyway. The only
remaining task is the refreshing of bwtwo1 when you return to it - it at
least will no longer be obscured by the bogus X image.
I suppose it shouldn't be surprising that the keyboard state ('kbd_mode')
is correct within the respective environments; apparently this state is
allocated on a per-frame-buffer basis. Anyway it works, nicely. When you
finally quit X (by exiting the login xterm) you revert immediately to the
suntools in bwtwo1, with no disruption of color X11 to, for instance,
framemaker and back with no pause other than what it takes to move the
mouse... [Just discovered, it's feasable to run maker from inside X11 if
you can deal with the independence of refresh handling; it would be nice,
though, to have a tidy way of using both together...] Anyway, thought
others might like to know about this simple finagle.
Ken Manheimer klm@cme-durer.ARPA or ..!uunet!cme-durer.arpa!klm
National Bureau of Standards, Factory Automation System, Software Support
------------------------------
Date: Sun, 31 Jul 88 12:45:19 EDT
From: jjb@zeus.cs.wayne.edu (Jon J. Brewster)
Subject: Problems: ypserv & nameserver on SUNOS 3.5
I recently obtained the nameserver kit from Sun Tech Support and installed
the nameserver and new ypserv, as well as the MX version of sendmail. All
three seem to work, although not quite as I had expected. I expected that
yp would now invoke the nameserver to resolve queries which could not be
found in the local maps. Am I being naive, or should something like ftp
foo.some.where now work? (Assuming the nameserver can resolve
foo.some.where)
A second surprise is in sendmail -- it seems to use the resolver and send
messages properly, but the construct $%y in sendmail.cf matches anything
and everything, whereas it used to match only keys in the hosts yp map.
Have others had similar experiences are am I doing something wrong?
------------------------------
Date: Sat, 30 Jul 88 20:32:43 -0500
From: monty%tartarus@gargoyle.uchicago.edu
Subject: Problems with groups under PC-NFS
as noted in a recent entry to this forum, groups for pc clients under
pc-nfs do not appear to work correctly, or at least not fully. the
problem seems to be that pc-nfs only uses the group listed in the
/etc/passwd file on the server when establishing group identities for our
pc clients. this would work fine if everyone were in the same group or if
individuals did not have responsibilities that crossed groups, but
unfortunately, that isn't how our workgroups operate here. we would like
to arrange a more layered group security scheme here such as would be
available under normal nfs environments. has anyone had similar problems
with groups under pc-nfs, and are there any 'work-arounds' ? thanks in
advance . . .
------------------------------
Date: Sun, 31 Jul 88 01:25:33 EDT
From: dff@morgan.com (Daniel F. Fisher)
Subject: Need info on RFC's
How can I get copies of NIC RFC's? Are they available through netland,
say, in an archive server? How would I make a request? Is there an
index?
Thanks in advance.
Daniel F. Fisher
(dff@morgan.com)
[[ The official repository of RFC's is the machine "SRI-NIC.ARPA". But as
far as I know they are only accessible via anonymous FTP. There is an
index there, too. But I don't know of any archive accessible from
Usenet-land. --wnl ]]
------------------------------
Date: Mon 1 Aug 88 06:03:58-PDT
From: Bob Knight <KNIGHT@csli.stanford.edu>
Subject: SUN-2 disks?
Hi - I own a 2/120, and need to get some new disks for it to replace some
aging Fujitsus. What I'm interested in is a "plug-and-play" solution with
either:
o some SMD disks, either used or new that don't chew up
a lot of power, are reliable, and small
o or, a Multibus SCSI interface off of which I can hang some
(recommendations?) SCSI disks that will play with SunOs out
of the box
I want to have at least 150 megabytes, 300 would be preferable. Any help
would be VERY much appreciated. Please keep in mind that cost is not an
overriding concern but is quite high on the list.
Please mail responses to me directly, as I'm not on the list. If there's
any interest, I will summarize responses to the list.
Thanks,
Bob Knight
knight@csli.stanford.edu
------------------------------
Date: Sat, 30 Jul 88 02:35:34 EDT
From: mcintyre@turing.cs.rpi.edu (David McIntyre)
Subject: Photographic Output Devices?
I am interested in purchasing a photographic output device for our Sun
3/110C. The type of device we are looking at is something like the Matrix
recorder, that has a small monochrome screen viewed through RGB filters to
get the composite color.
35mm output is a must, Polaroid back availability would be nice, if not
too expensive.
I think that this type of device goes for a couple of $1000's, but we
aren't interested in a mega-bucks super-camera.
If anyone knows of the name and email or mail address of companies that
make such things please send me the info. If you have good or bad
experiences with certain instruments I would also be interested in hearing
about them.
Thanks,
Dave
Dave "mr question" McIntyre
home : 518-276-5842
office : 518-276-8633
mcintyre@turing.cs.rpi.edu
------------------------------
End of SUN-Spots Digest
***********************