Sun-Spots-Request@Rice.edu (William LeFebvre) (09/08/88)
SUN-SPOTS DIGEST Wednesday, 7 September 1988 Volume 6 : Issue 220
Today's Topics:
Re: data acquisition to Sun 3 (2)
Re: YP updates, "Can't get an address for server ."
Re: Text previewers (Postscript)?
Re: broadcast storm at boot time
Re: rolo
Exabyte tape drives; fast remote saves
Problem: diskless clientss waiting on disk
Problems with atrun under 3.5
tcsh diffs for SunOS 3.5 csh
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: 6 Sep 88 16:55:42 GMT
From: felix!arcturus!dav@hplabs.hp.com (David L. Markowitz)
Subject: Re: Data acquisition to Sun 3 (1)
Reference: v6n214
Ned Danieley <ndd@sunbar.mc.duke.edu> writes:
> We are interested in acquiring data to a Sun 3/160....we would like to go
> to an even higher data rate (about 500k bytes per second)...Does anyone
> have any experience transferring large amounts of data into VMEbus
> memory?...
We have done exactly the same thing. I used a VME Microsystems Inc. 32
bit DMA board in a Sun 3/280. Because of the non-real-time nature of Sun
OS, we built a custom "buffer box" to buffer the constant data stream we
wanted to collect against the burst transfers to the Sun. Our goal was
550KB/s. We didn't achieve it (because someone decided to only put 256K
in the buffer box), but we found that we would have been capable of ~700KB/s
with a very large buffer. A 1MB buffer would be large enough to achieve
500KB/s.
These rates were measured doing DMA in to Sun memory (not VME memory) and
out to a Fuji 2333 (280M disk) using a Xy451. A faster SMD controller
would help a lot too. I wrote a driver for the DMA board, and our
application program which drives things is interesting too. It uses
shared memory to communicate with two other processes doing data reduction
and graphic displays in real-time while collecting the data! We found the
3/280 to be a real good machine for this.
David L. Markowitz Rockwell International
dav@arcturus ...!sun!sunkist!arcturus!dav
[[ Note that "dav@arcturus" is not a valid address in most
domains. --wnl ]]
------------------------------
Date: Tue, 6 Sep 88 17:44:44 EDT
From: c31!vaillan@ireqs3.UUCP (Clement Vaillancourt )
Subject: Re: data acquisition to Sun 3 (2)
Reference: v6n214
Yes, it is possible to do data acquisition with dual port memories on the
VME bus. We just completed an A/D to VSB bus interface to connect various
A/D to a dual ported VME/VSB memory. The memories we are using are 12 mb
modules from Micro Memory Inc. 9540 Vassar Ave. Chatsworth, Ca.
(818-998-0070). Other modules from 4 to 16 mb are available. We are
writing one A/D data (16 bits) every micro-second into those modules via
the VSB port. The write cycle is about 350 ns so we can even look at the
data with a read cycle from the cpu on the VME bus when the data is
comming in! To acces the memory we map it, no special i/o driver are
required.
We are taking this route because our need is to build 3 Sun based data
acquisition systems, each with 32 analog inputs connected to 32 A/D and 32
memory modules. The total capacity of a system will be 32 milions samples
per second for 6 seconds.
Yes, each system will have 32 x 12 mb = 384 mb. of outboard memory. We
are using two 21 slots Force VME chassis per system to put the 32 memory
modules and we connect those chassis to the Sun 3/160 with two VMEbus
Repeater 2000 from HVE Engineering Inc. from 1684 Dell Ave, Campbell, Ca.
(408-370-4666).
We intend to upgrade to Sun 4 and SunOs 4.0 soon, and we will also build
an other interface to use those memories in a rotating buffer mode with
external trigger to freeze the data in memory. When this is done the
system will be more or less equivalent to a high capacity digital scope.
Clement Vaillancourt,
Hydro-Quebec Research Institute
1800 Montee Ste-Julie, Varennes, P. Quebec, Canada, J0L 2P0
Tel.: 514-652-8238 Fax.: 514-652-8299 or 514-652-8180
UUCP: ...ireqs3!vaillancourt
vaillancourt@ireqs3.uucp
------------------------------
Date: Tue, 6 Sep 88 15:58:17 PDT
From: sklower@okeeffe.berkeley.edu (Keith Sklower)
Subject: Re: YP updates, "Can't get an address for server ."
We got this symptom once after having manually added a YP server
via
makedbm -u `domainname`/ypservers{,}
and having mistakenly included a blank line in the resulting ascii file.
------------------------------
Date: Wed, 7 Sep 88 10:48:09 EDT
From: gfr%wolfgang@gateway.mitre.org (Glenn Roberts)
Subject: Re: Text previewers (Postscript)?
Reference: v6n219
(Beth Elias):
> Is there a previewer (postscript most wanted) that would
> allow the fully formatted text to be displayed to the
> workstation monitor?
The most obvious answer is Sun's NeWS system (last I looked NeWS was
essentially a give-away at $100, which includes the two Adobe books on
PostScript). In NeWS applications 'client' processes communicate with a
window 'server' process (not necessarily on the same machine) using
PostScript. NeWS includes a program called psview which displays any
PostScript thrown at it.
I also saw an ad for a product called PSView which bills itself as "The
first interactive previewing system fully PostScript compatible". Cost is
$195. I know nothing more about this product. Contact Pipeline
Associates Inc., 239 Main St., W. Orange NJ, 07052 (201)- 731-7860.
(I have no association with Sun or Pipeline Associates, etc...)
Glenn Roberts, MITRE Corp, McLean VA
gfr%wolfgang@gateway.mitre.org
------------------------------
Date: Tue, 6 Sep 88 15:28:02 PDT
From: sklower@okeeffe.berkeley.edu (Keith Sklower)
Subject: Re: broadcast storm at boot time
To: smb@research.att.com (Steve Bellovin)
In your submission to sun-spots you claim to be running 4.3-tahoe-beta on
your CCI machine which has a certain bug unfixed concering ICMP subnet
mask requests. The problem has been fixed for the genuine 4.3-tahoe
release.
[[ Mr. Bellovin added "I should have known that, and did indeed remember
-- after I had sent the note -- that of course I had that code lying
around from the Berkeley release of it." --wnl ]]
------------------------------
Date: Tue, 6 Sep 88 15:08:54 PDT
From: ultra!ted@ames.arc.nasa.gov (Ted Schroeder)
Subject: Re: rolo
Here's an interesting one. Rolo crashes with a segmentation exception (on
a Sun 3/50 running SunOS 3.4) if you have /Text/Retained set to "Yes" from
the defaults menu. (The default is "No", natch). Anybody seen anything
like this before? Is there anything we can do other than change the
default?
Ted Schroeder ultra!ted@Ames.arc.nasa.GOV
Ultra Network Technologies
2140 Bering drive with a domain server:
San Jose, CA 95131 ted@Ultra.COM
408-922-0100
------------------------------
Date: Tue, 06 Sep 88 14:04:35 -0700
From: Tim Morgan <morgan@ics.uci.edu>
Subject: Exabyte tape drives; fast remote saves
We recently received our first Exabyte tape drive. It's connected to a
Sun SCSI board in a 4/260 (running SunOS 4.0) and we're using the Sun
device driver. So far, the maximum sustained throughput I've been able to
measure has been 239 KB/second, doing back-to-back writes of 63KB buffers,
although the claimed speed of the device is 246KB/s. The speed of the
host doesn't seem to matter, as I measured the same 239 KB/s when the
Exabyte was connected to a 3/280 instead of a 4/260. Has anyone been able
to achieve 246 KB/s?
I then began to develop some new software to do filesaves. Right now I
have a tar-like program which does saves, either locally or remotely,
while the system is up. The remote saves are done through a TCP
connection to an rmt-like program which accepts connections and passes the
data through to the Exabyte. I've spent quite a bit of my free time over
the last week tuning these two programs, and I'm now able to do remote
saves at the same speed as local ones: 239 KB/s (14 MB/minute). This is
saving files which are local to a 3/280 (with Xylogics 451 controllers and
one Eagle disk/controller) to the Exabyte connected to the 4/260, with no
intervening gateways. Both systems are running SunOS 4.0 with the stock
TCP/IP. The saving program consumes about 38% of the CPU time on the
3/280. To achieve this speed, I had to use several features specific to
SunOS 4.0 (shared memory, memory-mapped files). The total code so far is
about 700 lines of C. It contains #ifdef's so that the programs can run
on earlier versions of SunOS or on 4.[23]BSD systems, but the throughput
won't be as great (I plan to do some additional tests to see how fast I
can make it run under these conditions).
We plan to have a front-end program which the operator will run. It will
read a file similar to a makefile which specifies which machines and
filesystems need to be backed up on any particular day, and whether the
backup should be an incremental or a fullsave. All the operator should
have to do is type "backup". Because the saves are done with the system
up, the operator does not need physical access to the machine being backed
up; only to the Exabyte drives so he can change tapes.
Most restores we do are actually to recover files which a user has deleted
accidently, so we plan to have a restore program which can tell us which
backup tapes contain versions of file "X", along with the size and last
modification dates, so we can choose the correct version to restore.
There's also an interactive program, similar to the 4.2 "restore" program
which allows you to mark desired files for restoration. Then you'll just
load the correct tape in the drive and type "go" to restore the desired
file(s). It'll sort the files to be restored by their position on the
tape, so only one pass will be needed.
Tim Morgan
UC Irvine ICS Dept.
------------------------------
Date: Tue, 6 Sep 88 17:15:50 PDT
From: richk@humpback.cs.washington.edu (Richard Korry)
Subject: Problem: diskless clientss waiting on disk
The setup is: the server is a 3/280 running 3.3 with 8mb. the 3 diskless
clients are 3/60 running 3.5 with 12mb. The problem is that occasionally
my 3/60 will just stop in its tracks and a 'ps' reveals that processes are
waiting for disk (D). The client's biods are all inactive and swapped. At
least one of the server's biod's is Sleeping. The nfsd's are also
sleeping. A perfmon shows basically no activity on the server. Eventually
(a minute or two) everything pops back to life. Nothing is being print by
any console other NFS server not responding. Any ideas?
rich
------------------------------
Date: Tue, 06 Sep 88 18:48:16 PDT
From: Liza Weissler <liza%rcc@rand-unix.arpa>
Subject: Problems with atrun under 3.5
We've also had problems with atrun under 3.5; requests spooled with either
the 3.4 or 3.5 at bomb out with 'bad spool header' errors. I reinstalled
the 3.4 version of at and friends and (of course) it works fine, but I'd
really like to know what the problem is with the 3.5 version.
Liza Weissler
The RAND Corporation
------------------------------
Date: Wed, 7 Sep 88 04:44:53 CDT
From: Jim "Cookie" Thompson on concave <convex!jthomp@a.cs.uiuc.edu>
Subject: tcsh diffs for SunOS 3.5 csh
Apply this diff, stir well, compile for 5 minutes at 350 deg F. Serve to
your friends.
Enjoy,
Jim Thompson Convex Computer Corporation 701 N. Plano Road
(214) 952-0536 Richardson, Texas 75081 jthomp@convex.COM
__________
RCS file: sh.sem.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -c4 -r1.1 -r1.2
*** /tmp/,RCSt1020343 Wed Sep 7 04:40:35 1988
--- /tmp/,RCSt2020343 Wed Sep 7 04:40:36 1988
***************
*** 132,139
* save and restore the current sigvec's for
* the signals the child touches before it
* exec's.
*/
omask = sigblock(sigmask(SIGCHLD));
ochild = child; osetintr = setintr;
ohaderr = haderr; odidfds = didfds;
oSHIN = SHIN; oSHOUT = SHOUT;
--- 132,150 -----
* save and restore the current sigvec's for
* the signals the child touches before it
* exec's.
*/
+
+ /* Sooooo true... If this is a Sun, save
+ * the sigvec's.
+ */
+ #ifdef sun
+ typedef struct sigvec * SVSP;
+ struct sigvec oSIGINT, oSIGQUIT, oSIGTSTP, oSIGTTIN,
+ oSIGTTOU, oSIGTERM, oSIGHUP;
+ int Sun_omask;
+ #endif sun
+
omask = sigblock(sigmask(SIGCHLD));
ochild = child; osetintr = setintr;
ohaderr = haderr; odidfds = didfds;
oSHIN = SHIN; oSHOUT = SHOUT;
***************
*** 138,145
ohaderr = haderr; odidfds = didfds;
oSHIN = SHIN; oSHOUT = SHOUT;
oSHDIAG = SHDIAG; oOLDSTD = OLDSTD; otpgrp = tpgrp;
Vsav = Vdp = 0; Vav = 0;
pid = vfork();
if (pid < 0) {
(void) sigsetmask(omask);
error("No more processes");
--- 149,176 -----
ohaderr = haderr; odidfds = didfds;
oSHIN = SHIN; oSHOUT = SHOUT;
oSHDIAG = SHDIAG; oOLDSTD = OLDSTD; otpgrp = tpgrp;
Vsav = Vdp = 0; Vav = 0;
+ #ifdef sun
+ (void) sigvec( SIGINT, (SVSP)0, &oSIGINT );
+ (void) sigvec( SIGQUIT, (SVSP)0, &oSIGQUIT );
+ (void) sigvec( SIGTSTP, (SVSP)0, &oSIGTSTP );
+ (void) sigvec( SIGTTIN, (SVSP)0, &oSIGTTIN );
+ (void) sigvec( SIGTTOU, (SVSP)0, &oSIGTTOU );
+ (void) sigvec( SIGTERM, (SVSP)0, &oSIGTERM );
+ (void) sigvec( SIGHUP, (SVSP)0, &oSIGHUP );
+
+ /*
+ * Can't handle any of these signals until sigvec's
+ * are restored
+ */
+
+ Sun_omask =
+ sigblock( sigmask(SIGINT) | sigmask(SIGQUIT) |
+ sigmask(SIGTSTP) | sigmask(SIGTTIN) |
+ sigmask(SIGTTOU) | sigmask(SIGTERM) |
+ sigmask(SIGHUP) );
+ #endif sun
pid = vfork();
if (pid < 0) {
(void) sigsetmask(omask);
error("No more processes");
***************
*** 145,152
error("No more processes");
}
forked++;
if (pid) { /* parent */
child = ochild; setintr = osetintr;
haderr = ohaderr; didfds = odidfds;
SHIN = oSHIN;
SHOUT = oSHOUT; SHDIAG = oSHDIAG;
--- 176,194 -----
error("No more processes");
}
forked++;
if (pid) { /* parent */
+ #ifdef sun
+ (void) sigvec( SIGINT, &oSIGINT, (SVSP)0 );
+ (void) sigvec( SIGQUIT, &oSIGQUIT, (SVSP)0 );
+ (void) sigvec( SIGTSTP, &oSIGTSTP, (SVSP)0 );
+ (void) sigvec( SIGTTIN, &oSIGTTIN, (SVSP)0 );
+ (void) sigvec( SIGTTOU, &oSIGTTOU, (SVSP)0 );
+ (void) sigvec( SIGTERM, &oSIGTERM, (SVSP)0 );
+ (void) sigvec( SIGHUP, &oSIGHUP, (SVSP)0 );
+ (void) sigsetmask(Sun_omask);
+ #endif sun
+
child = ochild; setintr = osetintr;
haderr = ohaderr; didfds = odidfds;
SHIN = oSHIN;
SHOUT = oSHOUT; SHDIAG = oSHDIAG;
------------------------------
End of SUN-Spots Digest
***********************