Sun-Spots Digest, v6n14
William LeFebvre
Sun-Spots-Request at RICE.EDU
Sat Feb 13 02:32:56 AEST 1988
SUN-SPOTS DIGEST Thursday, 11 February 1988 Volume 6 : Issue 14
Today's Topics:
Re: Question about mt and xt devices
Re: Is there a lprm command
Re: Spread sheet calculators
Lisp vs. C Floating Point Performance (Suns)
Floating-point answers
New Sun Disk Drive (model #'s)
Parity on terminal lines
NFS timeouts between Sun 4's and 3's
Bug in getservbyname() when running YP
Problems with SUN, IBM RT and netmail/sendmail
Problems with 892 MB disk drives
Dial in/dialback lines; getty gets in the way
Artecon - Sun Clones - Has anyone experience with them ?
"hyper-media" for Suns?
Running PC-NFS on a DN 3000?
Looking For Rob Lewis
Re: Mapping bad blocks to file names (includes shell script)
----------------------------------------------------------------------
Date: Fri, 29 Jan 88 17:58:05 EST
From: Dan Trinkle <trinkle at purdue.edu>
Subject: Re: Question about mt and xt devices
All unix really uses the /dev entries for is to give user processes a
convenient handle on major and minor device numbers. The major device
number is an index into the (block or character) device switch table.
This switch table contains structures of pointers to the correct driver
routines (open, close, read, write) to access the specified device.
I bet that the major device numbers for you /dev/mt* entries are the same
as the /dev/xt* entries if they were created. You can use mknod to create
a /usr/foo/bar/some-silly-tape-name file with the correct major and minor
device numbers, then use the command
tar cf /usr/foo/bar/some-silly-tape-name /tmp
and it will happily write the tape (assuming you have the write ring on
:-).
The stand-alone and boot utilities do not use the /dev entries, they have
this information compiled in, they probably don't even use major and minor
device numbers. Hence, internally they know what driver routines to use
to access the xt device, but only by name.
Daniel Trinkle trinkle at cs.purdue.edu ARPA
Computer Science Department trinkle%purdue.edu at relay.cs.net CSNET
Purdue University {ucbvax,decvax,ihnp4}!purdue!trinkle UUCP
West Lafayette, IN 47907 (317) 494-7844 PHONE
------------------------------
Date: Mon, 1 Feb 88 09:53:49 CST
From: ables at mcc.com (King Ables)
Subject: Re: Is there a lprm command
According to the latest Sun Software Technical Bulletin, this bug has
(finally) been fixed in SunOS 3.5. (I, as well as others, only began
reporting the bug under 2.0!).
-king
------------------------------
Date: Sat, 30 Jan 88 13:33:24 EST
From: rsalz at pineapple.bbn.com
Subject: Re: Spread sheet calculators
Look for the current SC to appear in two or three days in
comp.sources.unix newsgroup, and I guess the unix-sources mailing list. I
can be reached as rsalz at uunet.uu.net, sources at uunet.uu.net, and
rsalz at bbn.com /r$
oh yeah, I always use the $ instead of the S, unless I think sendmail is
gonna turn $a into today's date... :-)
For comp.sources.unix stuff, mail to sources at uunet.uu.net.
------------------------------
Date: Fri, 29 Jan 88 13:26:13 -0800
From: malcolm at spar-20.spar.slb.com
Subject: Lisp vs. C Floating Point Performance (Suns)
The times shown in the table below are number of seconds to calculate 10
iterations of a 1024 point FFT. In this study the C and Lisp version of
the FFT routine are identical. I started with Harry Barrow's FFT
benchmark (with declarations added by Lucid) and then translated it
statement by statement into C (thanks to Dave Singer for double checking
this.) I believe that this is as accurate a comparison as is possible.
Note, all of the Sun tests were measured with a version of Lucid Common
Lisp labelled "Development Environment 2.1.1". This lisp only does single
precision arithmetic using the 68881. Thus the only two lines that can be
directly compared are "Single 68881 C" versus "Lucid 2.1.1".
I believe it is now reasonable to conclude that Lisp compilers are as fast
as C compilers. I don't have any numbers for a prodution quality Lisp
compiler for the Sun/4's. I don't know of any reason the SPARC machine
would run compiled Lisp slower than C.
Finally, a word about register declarations in C: The times shown here
were measured by putting the variables I thought were most accessed into
registers. I did this with the same effort I normally go to make my own
programs fast. I did not do any exhaustive testing to find the best set.
When all of the register declarations are removed the 3/160 times got
slower by .8 seconds and all the 2/260 times got slower by about .4
seconds. The Sun 4/260 numbers did not change any indicating they are
doing global register optimization or the 4/260 is being completely
dominated by the floating point work. The Sun 3 no-register times make
sense since only the loop iteration and array addresses were put in
registers and thus they are independent of the floating point work.
Malcolm
***********************************************************
Time (in seconds) to execute 10 iterations of a 1024 point FFT
3/160 3/260 4/260
Double FPA C 2.4 1.5 0.8 (*)
Single FPA C 1.3 0.8 0.3 (*)
Double 68881 C 5.0 4.1 0.8 (*)
Single 68881 C 4.8 4.1 0.3 (*) <======
Lucid 2.1.1 4.7 4.0 <======
Symbolics Machine 4.7 (No IFU, No FPA - From Gabriel - Duplicated @ SPAR)
Symbolics Machine 3.9 (with either IFU or FPA - From Gabriel)
* Note that Sun4/260's only have one floating point option. They use
a pair of Weitek floating point chips.
The source code for both the Lisp and the C versions of this FFT benchmark
are available from me. Send mail to malcolm at spar.slb.com for more
information.
------------------------------
Date: Sat, 30 Jan 88 01:12:40 PST
From: quintus!ok at sun.com (Richard A. O'Keefe)
Subject: Floating-point answers
I've had mail from Cody @ ANL and Hough @ Sun.
The news is good: the messages from 'paranoia' *are* an artefact of the
use of extended-precision arithmetic for intermediate results and do not
mean that said extended-precision arithmetic is wrong.
There is a compiler switch "-fstore" which should make some such problems
go away; unfortunately in SunOS 3.2 only the Fortran compiler supports
this switch, so as 'paranoia' is coded in C I haven't been able to try it
out.
There is a newer version of MACHAR than the one held in NETLIB, which
should fix the problems I had with that.
The behaviour of DATAN2(0.0D0,0.0D0) will apparently be different in
SunOS4.0, but it still won't be an error. Apparently there is some use
for it being 0.0 or +/- pi, or something.
In case some people understood my previous message to be a criticism of
Sun's floating-point arithmetic, be disabused! I tried paranoia on a
certain '386 box and it crashed at a point where paranoia wasn't expecting
to crash...
The results from the ELEFUNT tests, by the way, were good.
------------------------------
Date: Mon, 1 Feb 88 13:24:57 CST
From: aydt%crl.cs.uiuc.edu at a.cs.uiuc.edu (Ruth Aydt)
Subject: New Sun Disk Drive (model #'s)
I ran across the following in the 3.5 release notes -- Chapter 4 "Changes
to Hardware and Software in Release 3.5":
"The NEC D2363 and Hitachi DK815-10 disk drives offer 900MB of formatted
storage, and 1GB of unformatted storage in the form of an SMD device that
is addressed by the xy driver. This disk comes in a nine ince rack mount
form factor"
Ruth Aydt
Research Programmer
Dept of Compter Science
University of Illinois at Urbana-Champaign
aydt at a.cs.uiuc.edu
------------------------------
Date: 1 Feb 1988 09:04-EST
From: Anund.Lie at gandalf.cs.cmu.edu
Subject: Parity on terminal lines
In sun-spots v6n9, Mike Jipping <jipping at frodo.cs.hope.edu> writes:
> random italics REALLY confused me. The problem was that the spooler was
> spooling with parity -- which the Epson, which was set to ignore parity,
Editor's comments:
> parity, regardless of the settings for EVEN and ODD. Out of curiosity,
> what would turning off both EVEN and ODD parity mean? It's quite possible
> that either one will work. --wnl ]]
It is possible that "stty -even -odd" (or equivalent) works consistently
for all Sun UNIX versions. It caused me a fair amount of trouble because
it is certainly not consistent between different BSD derivatives.
We have a number of terminals that are being used interchangeably on Sun's
and MicroVAXes w/ UNIX, VMS VAXes and other more strange systems. In
general we want to have 8 bits, no parity as standard. Unfortunately,
these terminals don't take lightly to getting characters with parity when
they are set to no parity themselves, with behavior that depends strongly
on the PROM revision number of the terminal. Sigh.
With a suitable terminal, it is easy to check what your driver does: Set
the terminal to a mode that uses bit 7 as a "attribute flag", set the
"attribute" to e.g. underline and check which characters are underlined
with respectively "stty even odd" and "stty -even -odd".
The documented meaning of the flags is what parity characters to allow
on input only.
(I may have got this wrong, it is some time since I actually did this, and
I'm not presently able to verify.)
- Both Sun UNIX (3.0) and Ultrix (1.1m) preferred "even parity"; that is,
unless even parity was specifically disallowed on input, they generated
and sent characters with even parity. (i.e. "stty even odd" and "stty
even -odd")
- One of the systems sent 8 bit characters without touching the parity bit
with "stty -even -odd". As far as I remember, the other just noticed that
it was not allowed to send even parity anymore and flipped to odd (!)
And, unfortunately, using LITOUT also suppresses the LF (NL) -> CR/LF
translation, so this is not a viable alternative for terminals at least.
(Both Even and Odd are boys' names in Norwegian: I once heard a talk by a
data communications person from a Norwegian company: "If I ever get twin
boys, I know what to call them .... ")
Anund Lie
Dept. of EE&CS ! Current address:
Division of Information Engineering ! Dept. of Computer Science
Norwegian Institute of Technology ! Carnegie Mellon University
N-7034 Trondheim, Norway ! Pittsburgh, PA 15213
E-mail (ARPA):
Anund.Lie at GANDALF.CS.CMU.EDU
( A_Lie%vax.runit.unit.uninett at TOR.NTA.NO )
------------------------------
Date: Mon, 1 Feb 88 00:34:05 EST
From: hedrick at aramis.rutgers.edu (Charles Hedrick)
Subject: NFS timeouts between Sun 4's and 3's
We have two Sun 4/280's, and a 3/280 that works as a cluster. They
mount each others' drives, and generally try to look identical. I
have noticed that writing files from the 4's to the 3 tends to be
slow. Indeed sometimes I get an NFS timeout. Today I got around to
investigating. It appears that the 4 simply overruns the 3. Using
nfsstat, you can see that many retries are happening. There are even
some retries between the two 4's, though things generally work better
there. I tried using a small wsize in the mount, but the best
performance results by simply not running biod. Biod attempts to
speed up write performance. In this case it speeds it up too much.
When we kill all the biod's, we get reasonable write throughput,
though of course writing is still slower than reading. This is using
sys4gamma on the Sun 4's. I haven't had a chance to put up the "real"
3.2 yet.
------------------------------
Date: Mon, 1 Feb 88 11:36:51 CST
From: ables at mcc.com (King Ables)
Subject: Bug in getservbyname() when running YP
Someone here came across the following bug in getservbyname(). I don't
know if anyone else has ever reported it or if anyone will really care to
fix it, but I will put it out here for your information and/or amusement.
It seems if one repeatedly calls getservbyname() on a host running Yellow
Pages (Vaxes as well as Suns, and probably others) some memory is
allocated that is either never released or never released correctly. The
effect is that the process grows indefinitely (as long as the calls are
being made).
Yes, I know, you should only really need to call it once at the
beginning... well, the people who found this weren't doing that. You
still shouldn't be able to kill yourself simply by making repeated calls
to something.
Here is the code to exercise the bug, in case you're interested. Since it
works "properly" on a host not running YP, I feel it is a bonafide bug.
-------
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
/*
* this program will grow indefinitely when compiled and run
* on a Unix host running Yellow Pages (both SunOS and Mt. Xinu).
* It will work properly on a host NOT running Yellow Pages.
*/
test ()
{
struct servent* sp; /* service */
sp = getservbyname ("finger","tcp");
return;
}
main ()
{
while (1)
{
test();
sleep (1); /* sleep else it eats memory VERY quickly */
}
}
-------
-king
ARPA: ables at mcc.com
UUCP: {gatech,ihnp4,nbires,seismo,ucb-vax}!ut-sally!im4u!milano!ables
------------------------------
Date: 1 Feb 88 15:42 +0100
From: Igor Metz <metz at iam.unibe.ch>
Subject: Problems with SUN, IBM RT and netmail/sendmail
We have a little problem here. We have a SUN-3/260 (SunOS 3.4) and an IBM
RT (AIX 2.1.2), and we would like to send mail from one machine to the
other. If we use 'netmail' to send mail from the RT to the SUN, the mail
arrives. But sending mail from the SUN to the RT fails.
I have no idea where to start with debugging. Is there anybody out there
who had a similar problem? Is it a similar problem like mailing between
SUN and LISP Machines (Sun-Spots V6 no 3)?
Thanks in advance for any hints
Igor Metz X400: metz at iam.unibe.ch or metz at iam.unibe.chunet
Institut fuer Informatik ARPA: metz%iam.unibe.ch at relay.cs.net
und angewandte Mathematik UUCP: ..!uunet!mcvax!iam.unibe.ch!metz
Universitaet Bern
Switzerland Phone: (+31) 65 49 02
------------------------------
Date: Tue, 2 Feb 88 05:41:38 EST
From: Steve M. Burinsky <smb at mimsy.umd.edu>
Subject: Problems with 892 MB disk drives
Sun now supports the NEC D2363. It's 1.1GB unformatted. And that brings
me to a question. The drive has 1024 cylinders, 27 heads, and 68
sectors/track (at 600 bytes per sector with overhead). We had several of
these drives running before Sun announced them.
In diag, we specified:
ncyl 1022 acyl 2 nhead 27 nsect 68 interleave 1
We just received Sun 3.5, and diag now has the 2363, but it says:
ncyl 964 acyl 2 nhead 27 nsect 67 interleave 1
What did I miss? Why are they throwing away about 50 MB? Did we mess up
on our format?
Steve
------------------------------
Date: Fri, 29 Jan 88 21:06:33 EST
From: perry at sambation.bellcore.com (Perry Metzger)
Subject: Dial in/dialback lines; getty gets in the way
I want to set up a serial port on my sun so that I can both dial in to it
and log in and have it dial me and let me log in. In other words, after
the modems connect when it is dialing me I want to get the "login:" prompt
and be able to log in normally.
Unfortunately, it seems impossible to send commands out to the modem
without getty and echo teaming up to play havoc with the commands. (The
modem uses a hayes style command set.)
Currently, I have a bizarre and almost too disgusting to describe hack
that runs suid root and runs sed over /etc/ttys to disable getty, sends a
sighup to init, diables echo, dials, enables echo, runs sed over /etc/ttys
again, sends init another sighup, etc. This is OBVIOUSLY NOT the right way
to do things, but I can't seem to get it working any other way. I could
get the modem to stop echoing and replying to any command, but that goes
away on this particular modem after a powerup and power outages are
frequent here. Simply disabling echo on the line won't work because getty
starts screwing things up when it sees return codes and the like. I am
getting desperate; does anyone know the right way to do this?
Perry
------------------------------
Date: 1 Feb 88 04:12:29 GMT
From: munnari!ditmela.oz.au!worsley at uunet.uu.net (Andrew Worsley)
Subject: Artecon - Sun Clones - Has anyone experience with them ?
These clones are about to be available in Australia and I would like to
know of anyone's experince with them. In particular how identical are they
to Suns. Are the Binary compatible ? Can you apply Sun kernel updates to
an Artecon kernel (assuming you are allowed to) ? What experience with the
suppliers and Sun like. So far here Sun are very much against them.
If I get a lot of response I will summarise for the net, removing
identifying parts for those that wish to remain anonymous.
Andrew Worsley
worsley at ditmela.oz.au
or
{..!uunet, ..!mcvax, ..!ukc}!munnari!ditmela!worsley
------------------------------
Date: Tue, 2 Feb 88 10:23:21 EST
From: sunpitt!cognac!elias at sun.com (Glenn S. Elias)
Subject: "hyper-media" for Suns?
Is there any public domain hyper-media (excuse the buzz word) available
for SUNs? Any help would be appreciated.
Thanks.
Glenn S Elias
Net Address: cognac!elias at pt.cs.cmu.edu
UUCP: ...{sun!sunpitt,cmucspt}!cognac
US Mail: Westinghouse R&D Center
1310 Beulah Road
Pittsburgh, PA. 15235
412-256-2706
------------------------------
Date: 2 Feb 88 18:31:56 GMT
From: acad!hans at hplabs.hp.com (Amar Hanspal @ Autodesk Inc., Sausalito, CA)
Subject: Running PC-NFS on a DN 3000?
Does anyone have experience getting PC-NFS 2.0 to run on a DN 3000? I've
had the opportunity to install it on a Sun 3/110, but I'm not sure on what
needs to be done to install it on an Apollo...
Please reply by e-mail if you can help !!
Amar
Amar Hanspal | uucp: {sun,hplabs}!acad!hans
| phone: (415) 332-2344 x.413
Autodesk Inc. | usmail: Autodesk Inc.
| 2320 Marinship Way
| Sausalito, CA 94965
------------------------------
Date: Thu, 28 Jan 88 20:37:59 EST
From: citi!dwon!lokkur!scs at rutgers.edu (Steve Simmons)
Subject: Looking For Rob Lewis
Rob Lewis responding to my posting on SCSI disks with some very
interesting stuff, but return mail is just not working. Please call me at
313-995-6366, or email your address and phone# to scs at lokkur.uucp.
Thanks, Steve
------------------------------
Date: 2 Feb 88 01:33:26 GMT
From: Rick Lindsley <richl at penguin.uss.tek.com>
Subject: Re: Mapping bad blocks to file names (includes shell script)
I don't have a C utility, but I do have a shell script called bname. Its
usage is "bname block# [block# ...] disk", and uses icheck and ncheck to
resolve its problems, and is 75 lines long. The block numbers you give it
are relative to the file system beginning (ie, how they are reported).
It's not perfect, particularly if the blocks are in the superblock. But it
works perfectly for blocks that have landed in files.
Rick
#!/bin/csh -f
#set echo
onintr getout
set path = ( /etc /usr/etc /bin /usr/bin /usr/ucb )
if ( $#argv < 2 ) then
echo "usage: bname block# [block#] disk"
exit 1
endif
foreach i ($argv)
if ( $i == $argv[1] ) then
set egreparg="^$i"
set blocks=$i
else if ( $i != $argv[$#argv] ) then
set egreparg="^$i|$egreparg"
set blocks="$blocks $i"
else
set disk=$i
endif
end
icheck -b $blocks $disk | egrep "$egreparg" | \
awk '$7 ~ /^inode=/ { \
split($7,tmp,"=") \
split(tmp[2],temp,",") \
if ($8 == "class=inodes") \
temp[1] = 1; # special marker \
if (inodes[temp[1]] == "") \
inodes[temp[1]] = $1 \
else \
inodes[temp[1]] = inodes[temp[1]] "," $1 \
} \
END { \
for (i in inodes) \
print inodes[i] " " i >> "'"/tmp/awk.$$"'" \
# print inodes[i] " " i \
}'
#
# now we have a comma-separated list of blocks (followed by the
# inode number) in /tmp/awk.$$. Let's construct an arg for ncheck ..
#
set inodes=`awk '{if ($2) printf ("%s ", $2)}' /tmp/awk.$$`
ncheck -i $inodes $disk |& grep -v ${disk}: > /tmp/nchk.$$
# now combine them
( cat /tmp/awk.$$; echo SWITCH; cat /tmp/nchk.$$ ) | awk '\
BEGIN { state = "blocks" } \
NF == 2 { if (state == "blocks") \
blocks[$2] = $1 \
else if (split(blocks[$1],tmp,",") > 1) \
printf ("%-25s blocks %s\n", $2, blocks[$1]) \
else \
printf ("%-25s block %s\n", $2, blocks[$1]) \
} \
$1 == "SWITCH" { state = "files" } \
END { if (blocks[1]) \
if (split(blocks[1],tmp,",") > 1) \
printf ("%-25s blocks %s\n", "in superblock", blocks[1]) \
else \
printf ("%-25s block %s\n", "in superblock", blocks[1]) \
if (blocks[0]) \
if (split(blocks[0],tmp,",") > 1) \
printf ("%-25s blocks %s\n", "unallocated", blocks[0]) \
else \
printf ("%-25s block %s\n", "unallocated", blocks[0]) \
}'
getout:
rm -f /tmp/*.$$
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list