Sun-Spots-Request@RICE.EDU (William LeFebvre) (09/08/87)
SUN-SPOTS DIGEST Tuesday, 8 September 1987 Volume 5 : Issue 40
Today's Topics:
Followup to Sun 3.4 problems
Re: IBM cabling system and Ethernet
Re: Sun-3 executables on a Sun-4
Re: Suns and high speed modems
Re: shelltool .vs. parity bit
Re: Root non-security on Sun workstations
VME disk controller review: Cheetah and Rimfire
Ciprico "Rimfire" VME controllers
register usage bug in SunOS 3.2 fortran compiler
Disk configuration
Want info/recommendations for databases on Suns
Executables from incompletely linked in functions?
Standalone application "under" Sunwindows?
Moving Console from bitmap to tty?
Color monitor for my 3/110?
"POP" icon
----------------------------------------------------------------------
Date: Fri, 04 Sep 87 09:39:49 PDT
From: Ed Hall <edhall%rondo@rand-unix.arpa>
Subject: Followup to Sun 3.4 problems
A couple of weeks ago I reported two serious problems with SunOS 3.4. In
one, TCP connections froze between Suns running 3.4 and certain of our
VAXen (but not others). In the other, running our graphics software on
Sun-3/160C's caused a kernel panic.
Some kind people at Sun have supplied us with a fix to the TCP problem.
It turns out that the problem occured whenever the initial sequence number
was ``negative'' (i.e. the MSB in what should be an unsigned 32-bit
quantity was on). Since on the day I was testing only our Internet
gateway was generating such numbers, only connections with that machine
had trouble. [Explanation for those unfamiliar with TCP: instead of
starting at zero, packet sequence numbers start at a clock-determined
value between 0 and 2^32-1. This makes it easy to reject ``old'' packets
that might be lurking around the Internet.]
In any case, Sun has a fix, and it works.
I've not been so successful in getting the other problem solved, though I
have determined that it occurs when the colormap is loaded. Sun is being
helpful here, too, but I've not had the time to do the necessary digging
(kernel stack traces and the like). Although Sun suggested that the
problem was caused by resizing an existing map, this does not seem to be
the case. Stay tuned.
-Ed Hall
Information Sciences Department
The RAND Corporation
------------------------------
Date: Fri 4 Sep 87 16:36:27-PDT
From: David Roode <ROODE@bionet-20.arpa>
Subject: Re: IBM cabling system and Ethernet
Someone out there must have been listening because I got some information
on one company's product which allows twisted pair to take the place of an
Ethernet transceiver cable. This is actually 2 twisted pair (4 wires) and
they could be taken from the IBM, DEC, or other building wiring system.
You still need a transceiver. The rough cost of the 2 units that go on
either end of the twisted pair to mimic a transceiver cable is $450.
Depending on the grade of the twisted pair, the length of the transceiver
connection can extend up to 250 meters. The product is known as an
Ethernet Expander.
The companies to contact for information are LANNET, 8 Hanechoshet Street,
Tel Aviv 69710, Israel 972-3-498811, 498247 or RAD Data Communications 151
West Street, Rochelle Park, NJ 07662 201-587-8822.
Considering that long transceiver cables often cost $200 or as much as
$600 for Teflon Plenum cable, this seems like an economical way to
engineer a connection in many cases.
------------------------------
Date: Fri, 4 Sep 87 17:11:03 PDT
From: hoptoad!gnu@cgl.ucsf.edu (John Gilmore)
Subject: Re: Sun-3 executables on a Sun-4
There is *a chance* that you will be able to run Sun-3 executables on a
Sun-4, but not with the software that comes with the first release. I
have been considering writing a 68020 emulator for the SPARC, and now that
Sun's Components Marketing group (+1 415 691 4190) has declassified the
SPARC Architecture Manual, there's a chance that I can do it. It won't be
running tomorrow though -- I don't even have a sales order confirmation on
my Sun-4 yet, two months after ordering it.
Sun may eventually provide something like this in the long run, but that
won't help people who upgrade; it'd be more for mixed networks.
John Gilmore
------------------------------
Date: Fri, 4 Sep 87 16:26:39 PDT
From: hoptoad!gnu@cgl.ucsf.edu (John Gilmore)
Subject: Re: Suns and high speed modems
I am running a Telebit modem at 19200 bps with my Sun-3/160 with little
trouble.
Suns currently come with two kinds of serial ports. Some are Zilog 8530
"SCC" chips -- the ones on the CPU board or on Multibus SCSI boards. The
rest are run by a Systech ALM card with fancy DMA support.
It turns out that because Tom Lyon did such a good job of making the SCC
ports run at high speeds, they run faster with lower overhead than the
fancy Systech ports, even though they have to take an interrupt for each
character. The Systech ports do fine for output, but due to brain damage
in their firmware, they have to take an interrupt per character on input,
and the Sun driver for the Systech isn't set up to handle this cheaply.
Thus running 19200 bps input on an SCC port takes <5% of my CPU, while
running 9600 bps input on a Systech port takes >90% of the CPU. The moral
is to put high speed modems on the two CPU ports, and leave the Systech
ports, if you have any, for terminals or low speed modems.
A Sun was the first to drive a Telebit modem running uucp spoofing at a
full 19200 bps; this uncovered timing bugs which were not detected in
testing with 3B2's, IBM PC AT's, etc. Many systems just CAN'T drive a
serial line at 19200 bps without gaps between the characters, even for
output. Suns can do it on both input and output, though they only
guarantee 9600 if you are doing both input AND output simultaneously on
the same port. Originally this was implemented for SRI, who had a DARPA
speech-to-data box that runs a full 9600 baud in both directions
continuously. Maybe someone from SRI can comment on how well this works.
Rob Warnock (sun!redwood!rpw3), an independent consultant, has offerred to
assist companies whose boxes can't handle high speed serial data. If you
have such companies' products and need them fixed, you might give them his
name. He's been building high speed serial products since at least 1975
(when I first used his Smart/Mux) and knows his business.
The Telebit modem runs at up to 18,000 bps on a clean line, while backing
off very gradually for less-than-perfect lines (the last site to call in,
unisoft, got 16425 bps transmit and 17520 on receive). Telebit is having
a half price sale of their uucp-compatible modem to sites in the uucp
maps; contact Mike Ballard at +1 408 996 8000. I have no connection to
Telebit except I beta tested this product and love it.
John Gilmore
------------------------------
Date: Sun, 06 Sep 87 15:44:32 PDT
From: grand!day@uunet.uu.net
Subject: Re: shelltool .vs. parity bit
> Does anyone know a way to convince shelltool (when in raw mode) not to
> throw away characters with the 8th-bit set.
This is a real botch. At the very least it should fold these characters
into the 7-bit realm like everyone else. What I hope they have already
done for the next release is make shelltool, cmdtool, etc. accept the ISO
8859/1 8-bit Western European character set with other 8-bit character
sets optional.
Can anyone figure out why vt100tool is not part of the standard release?
Better yet, vt220tool?
--dave
------------------------------
Date: 5 Sep 87 12:43:48 GMT
From: munnari!yabbie.oz.au!rcodi@uunet.uu.net (Ian Donaldson)
Subject: Re: Root non-security on Sun workstations
> What I want is a module that can be compiled into the workstation kernal
> that *will not allow a single-user boot*. Period. No rc files or
> profiles that some clever cracker will quickly edit out, no new
> complications to make these suckers harder to take care of.
If the user of the node has root access, then not much can be done to
prevent this I suspect.
What we did was simply modify /etc/init such that if /etc/secureinit
existed, /bin/login was exec'd instead of /bin/sh when a single-user shell
was needed. If login failed, or timed-out, then the system would come up
automatically. Its simple.
Also if /etc/secureinit existed, then SIGINT, SIGQUIT, SIGTSTP were masked
while /etc/rc was running, to prevent keyboard aborts at critical times.
Of course, if the user has root access and could remove /etc/secureinit...
I'm not talking about Sun's here in specific, as the mods weren't done for
a Sun, but the same probably applies I suspect for any machine where the
console is accessable to the general user, along with the reset button
and/or the mains plug.
Ian D
------------------------------
Date: 06 Sep 87 17:54:37 EST (Sun)
From: Rayan Zachariassen <rayan%ai.toronto.edu@relay.cs.net>
Subject: VME disk controller review: Cheetah and Rimfire
With the faster CPUs we've been seeing lately, we have noticed that too
many processes spend their wall clock time in disk waits. The disk i/o
subsystem indeed seems to be one of the top 2 bottlenecks (along with
memory starvation) for our systems. We've been looking for something
better than our trusty Xylogics 451's, which has been the default
controller around here until now. To our knowledge, there are three
companies in the market with high-performance controllers that are/will be
used in Suns, namely Interphase, Ciprico, and Xylogics. The contending
products are:
Interphase: 4200 "Cheetah"
Ciprico: 3200 "Rimfire"
Xylogics: 75* Sun default
At this time, I can release my evaluation of two of these boards. What
follows are my impressions of the products, along with a few numbers for
people who like to see the mundane stuff.
The boards compared are the Cheetah and the Rimfire. In summary, the
Cheetah is very fast on flat out reads (at 2MB/sec read, it approaches the
theoretical limit of 2.4MB/Sec for this disk, especially considering
sector control data). The Cheetah firmware fell flat on its face when
asked to do I *and* O interleaved, and degraded to about Xy451 performance
levels. In comparison, the Rimfire did 1.8MB/sec on a flat out read, but
did much better on mixed I/O. Based on this gross error in the Cheetah,
and the results of the benchmarks, I'd give the current overall
performance edge to the Ciprico board.
[[ The remainder of this message is a full and comprehensive review,
complete with tables and numbers. The entire message is available in the
archives as "sun-spots/disk-review": obtainable via anonymous FTP from
host "titan.rice.edu" or through the archive service (by mailing the
request "send sun-spots disk-review" to "archive-server@rice.edu"). --wnl ]]
------------------------------
Date: Tue, 8 Sep 87 10:49:31 +0200
From: mcvax!olsen!lance@seismo.css.gov (Lance Berc)
Subject: Ciprico "Rimfire" VME controllers
We've been using a Ciprico 3200 for more than two months now and have had
no problems with it. We have two 2351A Eagles attached, and have been
beating on it as hard as we could to see if it would fail. So far we've
had no problems. The 3200 is a 32-bit controller with 512k cache and all
sorts of go-fast logic on board. We've averaged about a 60% cache hit
rate since turning it on. Its diag program is especially nice since it
runs in user mode. The boot roms work. All this for two thirds the price
of a 450/kludge board combination.
We were happy enough with the first one to buy two more. Haven't had time
to hook them up yet.
lance
Lance Berc mcvax!olsen!lance@uunet.uu.net
Olsen & Associates mcvax!olsen!lance@seismo.css.gov
Zurich, Switzerland lance@pescadero.stanford.edu
------------------------------
Date: 5 Sep 87 20:27:08 GMT
From: indik@garnet.ma.arizona.edu (Robert Indik)
Subject: register usage bug in SunOS 3.2 fortran compiler
The following fortran program, when compiled on a Sun 3/50 running SunOS
3.2 leads to a bug in register usage.
subroutine t
i=4
j=5
k=mod(i,4)*4+mod(j,4)
end
The fourth line expands into code that uses register d3, although the
program fails to save and restore d3 on entry and exit. This seems to
happen whenever mod is used twice in one expression where the divisor is a
power of two. To illustrate the type of problem that shows up as a
result, try running the result of compiling with:
f77 main.f test.c t.f
where t.f is as above, main.f is:
call test
end
and test.c is:
test_()
{
register i,j,k,l,m,n;
for(i=1;i<=10;++i)
{
n=i;
t_();
printf("i=%d n=%d\n",i,n);
}
}
This, of course is just to illustrate the bug. In practice the bug showed
up in the midst of an enormous piece of pure fortran code.
The bug can be worked around by dividing the calculation into two
statements:
k=mod(i,4)*4
k=k+mod(j,4)
This was murder to track down.
Robert A. Indik | Internet: amethyst!indik@arizona.edu
Dept. of Math. | UUCP: ..{allegra,cmcl2,ihnp4}!arizona!amethyst!indik
Univ. of Arizona | Bitnet: indik@arizjvax
Tucson, AZ 85721 | Phone: +1 602 621 4599
------------------------------
Date: Sun, 6 Sep 87 21:06:23 EDT
From: root@topaz.rutgers.edu (Charles Hedrick)
Subject: Disk configuration
In response to the question on disk configuration: On vanilla Unix
systems, our experience is that the heaviest use is the swap partition,
then root, and then /usr, with the actual user files being used much less
often. With 2 disks, we put swap partitions on both disks, root and /usr
on opposite disks, and user files on both disks. However with a file
server things change slightly, because you aren't concerned about swapping
on the server so much as clients' swapping. So we split the clients
evenly between the two disks. Then we put /pub and /usr on opposite
disks, and split the user files. System V keeps statistics on disk
activity by cylinder (actually groups of cylinders), which lets you figure
these things out. Maybe as part of their SVID support, Sun would
implement this. By the way, you won't get any extra I/O throughput by
adding another disk if it uses the same controller. At least not with any
version of SunOS we have seen so far. If you need more I/O bandwidth, get
another controller with your disk.
Somebody asked whether anyone had tried an SMD disk on a 3/140. We are
using a 3/140 as a file server. Mounting in a rack requires some
homegrown mounting, and the SMD disk cabling isn't designed for it, but
there is no problem other than these mounting issues. The 3/140's slots
are standard. There just aren't as many of them.
------------------------------
Date: 4 Sep 87 21:55:41 GMT
From: danq@sag4.ssl.berkeley.edu (Daniel Quinlan)
Subject: Want info/recommendations for databases on Suns
I am trying to evaluate database systems for use in relatively small
(<<10,000 records per table) databases on a network of Sun workstations.
There seems to be quite a few database systems, but we have arbitrarily
limited consideration to three: Unify, Informix and /rdb. (Ingres was
eliminated on the basis that it was too difficult to use.) Unify and
Informix seem pretty similar on the basis of their manuals, with Unify
having the advantage of being supported by Sun. /rdb is quite different,
using principally flat text files with many small programs and/or shell
scripts; the company recommends shell programming to provide interfaces to
a database. This approach has a great appeal on the face of it, but I'd
like to hear from other people who have used /rdb. I'd appreciate any
information pro or con about the other two as well. Please mail to me and
I'll summarize. Thanks.
danq@sag4.ssl.berkeley.edu
------------------------------
Date: 5 Sep 87 04:08:19 GMT
From: harvard!cvbnet!blazer!aperez@eddie.mit.edu (Arturo Perez)
Subject: Executables from incompletely linked in functions?
On a Sun running OS 3.2, I have the need to create a library in which it
is possible to only link in a subset of the available subroutines. I also
need to be able to detect when a subroutine is not loaded.
Basically, what I want to do is NOT link in a function and still be able
to create an executable image. I also have to be able to tell at runtime
whether or not that subroutine is available. I looked into the
incremental loading capability given by the -A option to ld(1) but I could
not actually tell if the function was loaded or not after the image was
created (and actually the routine is never loaded with the -A option, is
it?).
Is there any hope of doing this under UN*X? On a Sun?
I JUST HATE TO BE SHOWN UP BY VAX/VMS and, worse yet, IBM VM/CMS!
Please reply directly to ...harvard!cvbnet!blazer!aperez, I can only read
news occasionally. If you may also be interested in such a thing, drop me
a line and I'll let you know.
Thanx to all concerned.
------------------------------
Date: 6 Sep 1987 1122 GMT (Sunday)
From: tve%rigi.uucp%cernvax.bitnet@jade.berkeley.edu
Subject: Standalone application "under" Sunwindows?
I am writing a program which needs full access to the cgtwo color board
because it plays directly with the hardware to obtain double buffering.
Usually such a program would have to be run in standalone mode (i.e. no
suntools running). For more ease of use (it's a pain to exit & re-enter
suntools all the time) I want to start the program from suntools, have it
"grab" the display and mouse/kbd (to take over from suntools), and restore
everything before it terminates.
My questions are:
1) How can I grab the cgtwo display? If I have to open the root window,
how can I determine it's name (I also have a b/w display)?
2) How can I grab input (mouse & kbd)?
3) How can I do all this without linking in the sunwindow library? (I
hate the linking time and the huge executable!)
Anybody have suggestions? Especially 3) worries me...
Thorsten
tve@ethz.uucp - Thorsten von Eicken - ETH Zuerich `, Switzerland
------------------------------
Date: Fri, 4 Sep 87 14:22:41 EST
From: mckay@courageous.ecn.purdue.edu (Dwight D McKay)
Subject: Moving Console from bitmap to tty?
I've got a couple of Sun file servers with bitmapped displays as their
consoles. I'd like to switch the console to use ttya and still be able to
use the bitmapped display. I need this capability so that the bitmapped
display can be placed in a more public area and because our console
switcher needs a console on a RS-232 line.
Sun claims you can't do this. Has anyone tried? Is there a way to have
your console terminal on ttya and use the attached bitmap screen?
--Dwight Mckay, ECN Workstation Software Support
[arpanet: mckay@ee.ecn.purdue.edu, usenet: ...ihnp4!pur-ee!mckay]
[Compu-serve: 75776,1521, office: EE 348B, phone: (317) 494-3561]
------------------------------
Date: 4 Sep 87 19:47:05 GMT
From: boulder!stevea@boulder.colorado.edu (Steven Johnson)
Subject: Color monitor for my 3/110?
I've got a new 3/110 on my desk that I look at through a dinky 15" color
screen and I've got the money to buy a real monitor. I'm also little
better than a total novice. Any advice along the lines of quality, deals,
or favourites of you seasoned sun-users?
------------------------------
Date: Fri, 4 Sep 87 11:02:53 PDT
From: rtilson@sun.com
Subject: "POP" icon
All these icons have prompted me to throw in one of mine. It has
proven to be rather POPular around here.
Enjoy.
/* Format_version=1, Width=64, Height=64, Depth=1, Valid_bits_per_item=16
*/
0xAAAB,0xFFFF,0xFFFF,0xAAAA,0x5557,0xFFFF,0xFFFF,0xD555,
0xAAAF,0x003F,0xFC00,0xEAAA,0x555E,0x7FFF,0xFFFE,0x7555,
0xAABC,0x8001,0xC001,0x3AAA,0x5579,0x0000,0x8000,0x9D55,
0xAAF2,0x0004,0x3000,0x4EAA,0x55E4,0x220C,0x4804,0x2755,
0xABC8,0x6604,0x080C,0x13AA,0x5790,0x2204,0x3004,0x09D5,
0xAF20,0x2204,0x4004,0x04EA,0x5E40,0x220E,0x7804,0x0275,
0xBC80,0x7700,0x000E,0x013A,0x7900,0x0000,0x0000,0x009D,
0xF200,0x0000,0x0000,0x004E,0xE400,0x0000,0x0000,0x0027,
0xC826,0x0000,0x0000,0x0C13,0xD069,0x0000,0x0000,0x120B,
0xD029,0x0000,0x0000,0x020B,0xD029,0x0347,0x0D08,0x0C0B,
0xD029,0x04C9,0x9310,0x100B,0xD076,0x0850,0xA124,0x1E0B,
0xD000,0x0810,0xA044,0x000B,0xD000,0x0850,0xA17C,0x000B,
0xD000,0x0C99,0x3244,0x000B,0xD000,0x070E,0x1CC4,0x000B,
0xF000,0x0000,0x0000,0x000F,0xF000,0x0000,0x0000,0x000F,
0xF000,0x0000,0x0000,0x000F,0xF0C0,0x0001,0x8000,0x030F,
0xF120,0x0003,0xC000,0x048F,0xF920,0x0007,0xE000,0x011F,
0xFCE0,0x0007,0xE000,0x00BF,0xF820,0x0003,0xC000,0x049F,
0xF0C0,0x0001,0x8000,0x030F,0xF000,0x0000,0x0000,0x000F,
0xF000,0x0000,0x0000,0x000F,0xF000,0x0000,0x0000,0x000F,
0xD000,0x0000,0x0000,0x000B,0xD000,0x0347,0x1C04,0x000B,
0xD000,0x04C9,0x880A,0x000B,0xD030,0x0850,0x8812,0x020B,
0xD048,0x0810,0x9022,0x060B,0xD030,0x0850,0x903E,0x0A0B,
0xD048,0x0C99,0x1122,0x0F0B,0xD048,0x070E,0x3E62,0x020B,
0xD030,0x0000,0x0000,0x020B,0xC800,0x0000,0x0000,0x0013,
0xE400,0x0000,0x0000,0x0027,0x7200,0x0000,0x0000,0x004F,
0xB900,0x7800,0x000F,0x009E,0x5C80,0x0801,0x8008,0x013D,
0xAE40,0x1002,0x000E,0x027A,0x5720,0x1003,0x8001,0x04F5,
0xAB90,0x2002,0x4009,0x09EA,0x55C8,0x2002,0x4006,0x13D5,
0xAAE4,0x0001,0x8000,0x27AA,0x5572,0x0000,0x0000,0x4F55,
0xAAB9,0x0000,0x8000,0x9EAA,0x555C,0x8001,0xC001,0x3D55,
0xAAAE,0x7FFF,0xFFFE,0x7AAA,0x5557,0x003F,0xFC00,0xF555,
0xAAAB,0xFFFF,0xFFFF,0xEAAA,0x5555,0xFFFF,0xFFFF,0xD555
Rick Tilson
rtilson@sun.com
{bone}!sun!dawn!rtilson
[[ Also available in the archives as "sun-icons/rt-pop.icon". --wnl ]]
------------------------------
End of SUN-Spots Digest
***********************