Sun-Spots-Request@Rice.edu (William LeFebvre) (10/03/88)
SUN-SPOTS DIGEST Saturday, 1 October 1988 Volume 6 : Issue 244
Today's Topics:
Re: A slow Sun network (3)
Spurious Watchdog resets.
386i C compiler bug
Notification on receiving new mail (shell scripts)
Rasterfile to rasterfile conversion filter
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: Mon, 26 Sep 88 18:08:41 EDT
From: hedrick@aramis.rutgers.edu (Charles Hedrick)
Subject: Re: A slow Sun network (1)
Reference: v6n236
In response to the message on "a slow Sun network": Chances are your network
is not slow. I don't know anything about your broadband technology. But if
this were a real Ethernet, 20 machines would be no problem. I think your
problem is more likely to be with your Suns. First, if you mean that you've
got 15 diskless clients on one server, that's a bit much. If you're going
to have any chance at making that work, you need a server with at least two
disk drives either on separate controllers or on a controller that can drive
both drives at full speed simultaneously (i.e. not the Xylogics 451 that
Sun sells, unless you're using two of them). I take it for granted that the
file server isn't being used for anything other than file serving. The
first thing I would do is try "vmstat 5". Look at the columns under the
names of your disks. That is I/O transfers per sec. The limit is about 37
for a Xylogics 451. This applies to the total of all disks controlled by
the 451. But a 5-sec average won't show peaks, so if you are seeing numbers
consistently around 30 or above, you may be at the limit of your disk
subsystem. The next thing to look at is the individual machines. How much
memory is on the clients, and what software and OS version are you running?
4MB is sort of marginal if you want really good performance. If you're
running big programs, it's less than marginal. Under 4.0, it's flatly
unacceptable. (4.0-specific problems can be fixed to a large extent by
moving back to the 3.2 version of Suntools, which works fine under 4.0.)
Again vmstat or one of the perfxxx things should be able to help you see
what is going on, but I can't give you any targets as to what is reasonable.
I'd be very surprised if changing to two Ethernets makes any difference,
unless there's something wrong with your broadband Ethernet.
------------------------------
Date: Mon, 26 Sep 88 16:53:55 MDT
From: dbd%benden@lanl.gov (Dan Davison)
Subject: Re: a slow sun network (2)
{would have replied to the sender but my mailer looked at his mail path
and laughed}
We've had similar problems with a 3/280 which typically has 120 processes
running at any given moment. The load average is not particularly high,
less than 8, but at times the machine really slows down. No paging, no
swapping at all. The last two or three times there was no ethernet load,
the load average was low, and there were no processes hogging memory (via
ps -aux). There were, however, an unusual number of context switches- >
70/second. So far that appears to be the only unusual number showing up
in performance monitors.
For comparison, another Sun-3/280 which is a client server (12 at the
moment) has typically 40-60 cs/second. The afflicted machine is a login
(editing, mostly) server.
I have no solution for the problem, but at least there's another data
point to examine.
dan davison / t-10 ms k710 / los alamos national laboratory / los alamos, nm
87545 USA / dd@lanl.gov (internet) / ...cmcl2!lanl!dd (old) dd@lanl.UUCP (new)
------------------------------
Date: 26 Sep 88 16:50:06 GMT
From: Rich Salz <rsalz@bbn.com>
Subject: Re: a slow sun network (3)
Reference: v6n236
>From: "SDRRTR::PSI%PRSRTR::PSI%SCRVX2::BLUE::IN%\"'m_mailnow::m_sdr::davis'@scr-gateway\""@sdr.slb.com
>
>I'm looking for clues or comments on the generally slow performance of our
>Sun network.
I'd start by reconfiguring your mail system... :-)
/rich $alz
------------------------------
Date: Tue, 27 Sep 88 10:39:09 +1000
From: Craig Bishop <munnari!lupus.cc.deakin.oz.au!craig@uunet.uu.net>
Subject: Spurious Watchdog resets.
> P.S. Have your Sun 4/110's been getting spurious Watchdog
> resets?
Sun have fixed this problem, we had it too.
It is a hardware revision problem of some sorts between Sun's internal
4/110s and ones that they ship to their customers. Anyway there is a new
trap.o which you can get from Sun which fixes this in software.
Craig Bishop ARPA: craig%lupus.cc.deakin.oz.au@uunet.uu.net
UUCP: ...!uunet!munnari!lupus.cc.deakin.oz!craig
------------------------------
Date: Mon, 26 Sep 88 14:50:58 EDT
From: gatech!stiatl!meo@cs.utexas.edu
Subject: 386i C compiler bug
This problem occurs in using cc under 4.0 SunOS on a 386i/150; we
currently have no other Suns on which to test.
Consider the program:
/********************/
#include "foo.h"
main ()
{
extern foo_type f(); /* foo_type is a pointer to a struct */
foo_type a, b, c, d;
<other definitions>
a = f ();
b = f ();
{
<other stuff>
c = f();
}
d = f ();
}
/********************/
At the 3rd & 4th invocations of f() (assigned to c @ line 14 & to d @ line
16), the messages
"foo.c", line 14: warning: illegal combination of pointer and integer, op =
"foo.c", line 16: warning: illegal combination of pointer and integer, op =
appear when the program is compiled. If the assignment to c is explicitly
cast, as in
c = (foo_type) f ();
or an additional extern statement is inserted in the scope of the inner
block, the 1st error message goes away, but the 2nd remains.
Don't ask why I'm doing this; it's irrelevant to the problem, which is
that the compiler is apparently going berserk during the scope changes.
Granted, the code still works, but
1) it's not right, and
2) there are actually LOTS of invocations of f (), and I have to wade
through lots of error messages during recompiles.
Just thought y'all might like to know...
Miles O'Neal Sales Technologies, Inc
gatech!stiatl!meo Atlanta, GA (404) 841-4000
------------------------------
Date: 16 Sep 88 05:21:43 GMT
From: Maarten Litmaath <mcvax!cs.vu.nl!maart@uunet.uu.net>
Subject: Notification on receiving new mail (shell scripts)
Reference: v6n226
There's a bug in the 'maild' shell script I sent you! To check if there's
new mail I compared the 'last access time' with the 'last modify time' of
the mailbox:
set sentry `ls -l $i`
# $ echo $*
# sentry -rw------- 1 maart 0 Sep 15 19:07 mailbox
mod="$6$7$8"
# $ echo $mod
# Sep1519:07
set sentry `ls -lu $i`
# $ echo $*
# sentry -rw------- 1 maart 0 Sep 15 19:06 mailbox
if expr "$mod" \> "$6$7$8" > /dev/null
This is the bug! In most cases it's allright, but what if the last modify
time were something like 'Oct 1 02:43' and the last access time 'Sep 30
20:03'? Furthermore it wasn't possible to 'ok' someone else's mailbox.
Another thing that's possible with the new version: being informed when a
directory has been changed - just specify the directory among your
mailboxes. Note that the layouts of the scripts have changed quite a bit.
(I left out the ^G's too, this time :-) BTW, I DO use the scripts myself
too!
Well, here follow the 2 sources again, it better be for the last time...
Thanks for your attention.
Regards,
Maarten Litmaath @ Free U Amsterdam:
maart@cs.vu.nl, mcvax!botter!maart
: This is a shar archive. Extract with sh, not csh.
: This archive ends with exit, so do not worry about trailing junk.
: --------------------------- cut here --------------------------
PATH=/bin:/usr/bin:/usr/ucb
echo Extracting 'maild'
sed 's/^X//' > 'maild' << '+ END-OF-FILE ''maild'
X#! /bin/sh
X
XDEFAULT=$HOME/mailbox
XMAILDF=$HOME/.maild
XTIMEOUT=180
XA= # place your ^G alarm sequence here
X
X
X[ $0 = sh ] || {
X [ $# -ne 0 ] || set $DEFAULT
X
X for i
X do
X [ -f $i -o -d $i ] || { echo $A$i not found.; exit 1; }
X done
X
X umask 077
X
X /bin/ls -ldu $* > $MAILDF
X
X sh < $0 &
X
X exit 0
X}
X
Xuser=`whoami`
X
X[ x$timeout != x ] || timeout=$TIMEOUT
X
Xwhile :
Xdo
X set sentry `who | awk '$1 == "'$user'" { print; exit }'`
X
X [ $# -ne 1 ] || exit 0
X
X tty=/dev/$3
X
X for i in `awk '{ print $8 }' < $MAILDF`
X do
X set sentry `ls -ld $i`
X
X [ $5 -ne 0 ] || continue
X
X date="$6$7$8"
X
X set sentry `grep " $i$" $MAILDF`
X
X [ "$date" = "$6$7$8" ] || echo $A\Mail in $i. > $tty
X done
X
X sleep $timeout
Xdone
+ END-OF-FILE maild
chmod 'u=rwx,g=rx,o=rx' 'maild'
set `wc -c 'maild'`
count=$1
case $count in
693) :;;
*) echo 'Bad character count in ''maild' >&2
echo 'Count should be 693' >&2
esac
echo Extracting 'ok'
sed 's/^X//' > 'ok' << '+ END-OF-FILE ''ok'
X#! /bin/sh
X
X(
XMAILDF=$HOME/.maild
XTMPF=$HOME/._maild
X
Xset sentry `awk '{ print $8 }' < $MAILDF`
X
Xshift
X
Xumask 077
X
X/bin/ls -ld $* > $TMPF
X
Xexec /bin/mv -f $TMPF $MAILDF
X) &
X
Xexit 0
+ END-OF-FILE ok
chmod 'u=rwx,g=rx,o=rx' 'ok'
set `wc -c 'ok'`
count=$1
case $count in
181) :;;
*) echo 'Bad character count in ''ok' >&2
echo 'Count should be 181' >&2
esac
exit 0
--
Alles klar, |Maarten Litmaath @ Free U Amsterdam:
Herr Kommissar? |maart@cs.vu.nl, mcvax!botter!maart
------------------------------
Date: Mon, 26 Sep 88 06:36:55 CDT
From: vixen!ronbo@cs.utexas.edu (Ron Hitchens)
Subject: Rasterfile to rasterfile conversion filter
I've been collecting and organizing a lot of bitmap files lately, most of
them as Sun rasterfiles. Most of the rasterfiles I accumulated were in
what is called "standard" rasterfile format. This is basically a plain
data dump of the bitmap, preceded by a descriptive header. Rasterfiles
can also be of the "byte-encoded" type, in this case the bitmap data is
run-length encoded, compressed, to save disk space. The encoding scheme
is very similar to the way MacPaint files are stored (it may even be the
same algorithm, I haven't checked).
Since my disk space was disappearing at an alarming rate, I decided to
convert all my rasterfile bitmaps to the compressed format. I whipped up
the following filter to convert Sun rasterfiles from one format to
another. It uses the standard library routine pr_load() to read in a
rasterfile, then uses pr_dump() to write it back out again. Pr_load()
automatically senses which type of rasterfile is being loaded and creates
a memory pixrect from it. Pr_dump() goes the other way, and you specify
whether you want the bitmap data stored in standard or encoded format.
Pr_load() will also recognize rasterfiles in the "old" format (the kind
used in the pre-2.0 days), so this filter can be used to update old
bitmaps to the current format(s).
The space savings from converting rasterfiles to encoded format can range
anywhere from roughly break-even, to a major win. I reduced the amount of
space needed to store about 100 bitmaps by more than half. Use the
file(1) command to determine whether a rasterfile is standard or
byte-encoded.
Since there is a lot of sleazy code out there which reads rasterfiles
directly, rather than using pr_load(), ras2ras will also convert from
encoded to standard format if needed.
BTW, you can make screendumps be compressed with the -e option, see the
man page for screendump(1). Or you can compress them after the fact with
this filter.
Ron Hitchens ronbo@vixen.uucp hitchens@cs.utexas.edu
__________
/*
* Raster to raster -- Load a Sun raster file and dump it back out in
* Sun raster format. What's the point? The library routine pr_load()
* will automatically load any one of the three rasterfile formats (old,
* standard or byte-encoded). The output rasterfile is written out
* in either byte-encoded (default) or standard format. So, this
* filter is useful for converting old format images to either the
* newer standard or byte-encoded formats, converting standard format
* (non-compressed) to byte-encoded (compressed) or vice-versa.
* Theoretically this filter can even read in a non-standard rasterfile
* and convert it to one of the regular Sun types, assuming a user
* provided filter is available in /usr/lib/rasfilters (see the Pixrect
* manual).
*
* Works equally well for color or monochrome raster files.
*
* This is a filter, but it sucks in the entire input pixrect and closes
* the input stream before opening the output file (if an ouput file
* name was provided). This means you can convert in-place by giving
* the same name for both input and output, ie:
* ras2ras foo.ras foo.ras
* Of course, that can't be done with shell redirection because of the
* way the shell sets up stdio.
*
* Note that programs which like to open raster files directly and read
* them will probably choke on byte encoded raster files, but they should
* be using pr_load() anyway.
*
* Usage: ras2ras [-s] [infile | -] [outfile | -]
*
* The -s arg means write the output rasterfile in standard format, the
* default output type is byte-encoded compressed, which can save a lot
* of space if there are large blocks of the same color in the image.
* Argument parsing is very simple-minded, only -s will be recognized,
* anything else will be taken as a filename. The pseudo filename "-"
* may be used as a placeholder in place of either the input or output
* filename, this is useful for terminating a pipeline, ie:
* foo blah.data | baz | bop | ras2ras - blurfl.ras
*
* Compile: cc -O -o ras2ras ras2ras.c -lpixrect
*
* Ron Hitchens, Sep 1988 ronbo@vixen hitchens@cs.utexas.edu
*/
#include <stdio.h>
#include <suntool/sunview.h>
main (argc, argv)
int argc;
char **argv;
{
FILE *in_fp, *out_fp; /* stdio pointers */
Pixrect *pr; /* temp pixrect handle */
colormap_t cm; /* temp colormap info */
char *progname; /* prog name from args */
char *filename; /* temp filename pointer */
int ras_type = RT_BYTE_ENCODED; /* default ras type */
unsigned char r [256], g [256], b [256]; /* colormap data */
progname = *argv; /* save prog name */
argc--; /* shift the args */
argv++;
in_fp = stdin; /* default to stdin/stdout */
out_fp = stdout;
if ((argc >= 1) && (strcmp (*argv, "-s") == 0)) {
ras_type = RT_STANDARD; /* output will be standard */
argc--;
argv++;
}
if (argc >= 1) {
if (strcmp (*argv, "-") != 0) { /* "-" is a no-op */
in_fp = fopen (*argv, "r");
if (in_fp == (FILE *)0) {
perror (*argv);
exit (1);
}
filename = *argv; /* save just in case */
}
argc--;
argv++;
}
cm.type = RMT_EQUAL_RGB;
cm.length = 256; /* provide space for the largest */
cm.map [0] = r; /* possible colormap */
cm.map [1] = g;
cm.map [2] = b;
pr = pr_load (in_fp, &cm); /* load in the pixrect */
if (in_fp != stdin) {
fclose (in_fp); /* close input stream */
}
if (pr == (Pixrect *)0) {
fprintf (stderr, "%s: pr_load() of %s failed\n", progname,
(in_fp == stdin) ? "stdin" : filename);
exit (1);
}
/* Now open the output file if not stdout, after closing input */
if (argc >= 1) {
if (strcmp (*argv, "-") != 0) { /* "-" is a no-op */
out_fp = fopen (*argv, "w");
if (out_fp == (FILE *)0) {
perror (*argv);
exit (1);
}
filename = *argv; /* save just in case */
}
}
/*
* Squirt the pixrect out the other end, note the colormap info struct,
* which was filled in by pr_load(), is passed on to pr_dump();
*/
if (pr_dump (pr, out_fp, &cm, ras_type, FALSE) != 0) {
fprintf (stderr, "%s: pr_dump() to %s failed\n", progname,
(out_fp == stdout) ? "stdout" : filename);
exit (1);
}
if (out_fp != stdout) {
fclose (out_fp);
}
exit (0);
}
------------------------------
End of SUN-Spots Digest
***********************