Sun-Spots-Request@RICE.EDU (William LeFebvre) (02/13/88)
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@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@cs.purdue.edu ARPA Computer Science Department trinkle%purdue.edu@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@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@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@uunet.uu.net, sources@uunet.uu.net, and rsalz@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@uunet.uu.net. ------------------------------ Date: Fri, 29 Jan 88 13:26:13 -0800 From: malcolm@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@spar.slb.com for more information. ------------------------------ Date: Sat, 30 Jan 88 01:12:40 PST From: quintus!ok@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@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@a.cs.uiuc.edu ------------------------------ Date: 1 Feb 1988 09:04-EST From: Anund.Lie@gandalf.cs.cmu.edu Subject: Parity on terminal lines In sun-spots v6n9, Mike Jipping <jipping@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@GANDALF.CS.CMU.EDU ( A_Lie%vax.runit.unit.uninett@TOR.NTA.NO ) ------------------------------ Date: Mon, 1 Feb 88 00:34:05 EST From: hedrick@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@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@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@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@iam.unibe.ch or metz@iam.unibe.chunet Institut fuer Informatik ARPA: metz%iam.unibe.ch@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@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@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@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@ditmela.oz.au or {..!uunet, ..!mcvax, ..!ukc}!munnari!ditmela!worsley ------------------------------ Date: Tue, 2 Feb 88 10:23:21 EST From: sunpitt!cognac!elias@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@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@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@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@lokkur.uucp. Thanks, Steve ------------------------------ Date: 2 Feb 88 01:33:26 GMT From: Rick Lindsley <richl@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 ***********************