Sun-Spots-Request@RICE.EDU (Vicky Riffle) (08/06/87)
SUN-SPOTS DIGEST Wednesday, 5 August 1987 Volume 5 : Issue 29
Today's Topics:
Anonymous FTP now available from "titan.rice.edu"
IBM cabling system and Ethernet
Why do our Sun 3/160 backups take 3+ hours? (6)
BITNET for Unix
Getty on non-console display?
disk drive questions
Query: third-party disk & tape drives?
dsun on SunView?
Just another pretty icon
------------------------------------------------------------------------
Date: Fri, 24 Jul 87 11:57:24 CDT
From: phil@rice.edu (William LeFebvre)
Subject: Anonymous FTP now available from "titan.rice.edu"
We have just finished setting up an anonymous FTP account for our primary
machine, "titan.rice.edu". As advertised in v5n28, the Sun-spots archives
are available directly from Rice via this account. I have already set up
an area for Sun source that is contributed via Sun-spots, and placed the
first shar file in that area: braggtools.shar. Our future plan is that
any message sent to sun-spots that contains a sizable amount of source (or
a sizable diff) will be sent out in the digest without the source and the
source will be placed in this area instead.
To access the Sun source archives, FTP to host "titan.rice.edu", login as
user "anonymous" or "ftp", use any password, and CWD to "sun-source".
There will always be two files: 00directory, which contains an "ls -l" of
the directory, and 00index, which contains brief descriptions of the
contents of the directory. Shell archive files can be transferred in
ASCII mode, but any tar files (should they ever exist) should be
transferred in "image" mode.
When the archives are placed on-line, they should be in the top-level
directory named "sun-spots".
By the way, there are a few other interesting programs in "public" that
aren't necessarily Sun-related (such as version 2.3 of "top" :-).
William LeFebvre
Department of Computer Science
Rice University
<phil@Rice.edu>
[[ Sun-spots archives are now available via anonymous FTP from host
"titan.rice.edu" in the directory "sun-spots". Currently, only volume 5
is on-line. The files are named v5nX, where X is the issue number. So,
this issue would be named "v5n29". --ed ]]
------------------------------
Date: Sun 26 Jul 87 17:28:39-PDT
From: ROODE@bionet-20.arpa (David Roode)
Subject: IBM cabling system and Ethernet
I think you might look to the Sun 3/50 connection for an External
transceiver as your mechanism for utilizing the IBM cabling system.
Several companies have products which extend the transceiver to host
connection and carry it over 2 twisted pairs. You then need only a
dedicated transceiver connection in the wire center for each Sun.
Multiport thin repeaters are fairly expensive per port as compared to
multiport transceivers. The savings in multiport thin repeaters is that
up to 31 computers with internal transceivers can be connected to each
port. Over the IBM cabling system you would have to use a second path
back to the wire center to take advantage of this with baluns.
I'm sorry I don't know who has the existing transceiver-cable-over-
standard-twisted-pair devices, but I understand 3COM has announced plans
for such a product, and I have heard of several others who sound as if
they have them out.
------------------------------
Date: 26 Jul 87 17:11:30 GMT
From: orcisi!michael@seismo.css.gov (Michael Herman)
Subject: Why do our Sun 3/160 backups take 3+ hours?
The bottom line was that dump was not using an appropriate blocking
factor. Thanks to the people at Sun and everyone else for your prompt
responses. All of the responses follow.
Michael Herman
Optical Recording Corporation
141 John Street, Toronto, Ontario, Canada M5V 2E4
UUCP: { cbosgd!utcs ihnp4!utzoo seismo!mnetor }!syntron!orcisi!michael
ALSO: mwherman@watcgl.waterloo.edu
[[ The responses have been inserted in the digest as if they were separate
messages. For those of you who came in late, the original poster's
configuration consists of a single 71MB hard disk and a 1/4" cartridge
tape drive. /usr, a 40MB file system that is about 95% full, took 3+
hours to back up. --ed ]]
------------------------------
From: rtilson@sun.com (Rick Tilson)
Subject: Re: Why do our Sun 3/160 backups take 3+ hours?
Try this. I use it on my 3/75 with 71 meg fujitsu and 1/4" tape.
dump 0ufdsb /dev/rst8 1000 3825 1750 /dev/rsd0g
This takes 11-15 minutes.
If you are using the c option to specify cartridge tape, your using very
minimum optins for length, density etc. This option was intended more for
the old 4 track tape drives in 100's and 120's.
------------------------------
From: yetti!gen1!tyler (Tyler IVANCO)
Subject: Re: Why do our Sun 3/160 backups take 3+ hours?
I believe your problem is common to all systems using streamer tape
drives. The problem is basically that unix cannot supply the streamer
drive with data fast enough. I had the same problem and wrote a small
block program that collects data from a pipe into a say, 1Mbyte buffer,
then uses a single write call to dump to stdout.
e.g.
dump 0f - | block -b 1024000 > /dev/rmt4
On my ICM3216, the file dump took 2 hours using
dump 0f /dev/rmt4
and less that 20 minutes using the dump/block combination.
The program is trivial.
Here is block.c. It uses getopt which was distributed by the net a while
back.
[[ The program is small enough and this issue is small enough, I decided to
include the source. It is also available on titan.rice.edu as
"sun-source/block.c" --ed ]]
#include <stdio.h>
#define DBUFFERSIZE 10240
main(argc,argv)
int argc;
char **argv;
{
extern int optind;
extern int getopt();
extern char *malloc();
extern char *optarg;
register char *buffer;
register int i,bsize,total;
int c, buffersize, quiet=0;
buffersize=DBUFFERSIZE;
while( (c=getopt(argc,argv,"qb:")) != EOF ) {
switch(c) {
case 'b': sscanf(optarg,"%d",&buffersize);
break;
case 'q': quiet++;
break;
default: exit(1);
break;
}
}
if(!quiet) fprintf(stderr,"Blocksize=%d\n",buffersize);
if((buffer=malloc(buffersize))==0) {
fprintf(stderr,"Not enough memory available\n");
exit(1);
}
for(c=0;c<buffersize;c+=256) *(buffer+c)=0;
total=0;
bsize=buffersize;
while( (i=read(0,buffer+total,bsize-total)) > 0) {
total+=i;
if(total>=buffersize) {
write(1,buffer,total);
total=0;
bsize=buffersize;
}
}
if (total) write(1,buffer,total);
close(1);
cfree(buffer);
exit(0);
}
------------------------------
From: omnitor!onfcanim!dave@watcgl (Dave Martindale)
Subject: Re: Why do our Sun 3/160 backups take 3+ hours?
What block size are you using on the tape? We have IRISes with 70Mb disk
and 1/4" tape drive, and it takes about a half hour to back up a 40Mb /usr.
We normally do our backups with cpio, which has an option to specify that
it write 250Kb blocks on tape. Tar writes 200Kb blocks on cartridge tape
by default. This allows the drive to write for a reasonable period after
it's spent all the time required to back up the tape and get it up to
speed before the block, then stop afterwards.
If you use the sort of blocksizes common on half-inch tape (10Kb), the
tape drive spends all day starting and stopping without writing much data.
------------------------------
From: seismo!rochester!srs!matt (Matt Goheen)
Subject: Re: Why do our Sun 3/160 backups take 3+ hours?
What blocking factor do you use. If you don't specify one it will default
to 10 which is VERY slow for cartridge tape. The magic number seems to be
126 (somehow derived from internal buffer sizes). So:
dump 0cfbu /dev/rst0 126
[[ Thanks also to Paul Czarnecki and Bill Shannon for similar
recommendations. --ed ]]
------------------------------
From: cramer@sun.com (Sam Cramer)
Subject: Re: Why do our Sun 3/160 backups take 3+ hours?
Yes, a large block size should help. The game here is to get enough data
into the tape controller so that it has a chance of streaming. You can
do this by repeatedly feeding it smaller blocks of data that make it into
the timing window necessary to keep the drive streaming, or you can repeatedly
feed it large blocks of data, each of which will stream.
Try playing with a large blocksize in tar or dump.
------------------------------
Date: Sun 26 Jul 87 17:19:08-PDT
From: ROODE@bionet-20.arpa (David Roode)
Subject: BITNET for Unix
I have been given a name at Penn State (Dave Eckard) regarding an RSCS
package for Unix. The phone number I have is 814-865-9505, but I have not
made any inquiries yet. Please let me know what you find out. As I
understand it, BITNET is moving to a network hardware upgrade for those
hosts desiring it. In this upgrade, a dedicated processor will service
the BITNET network and connection for a host. In this mode, RSCS will be
replaced by TCP/IP suite protocols, with something new to be specified for
the low level network service.
------------------------------
Date: 27 Jul 87 13:48:58 GMT
From: km@emory.UUCP (Ken Mandelberg)
Subject: Getty on non-console display?
We are getting a Sun 280 server which will live in a lifeless computer
room. I want to setup the EEPROM so that ttya is the console, which we
will connect to a printing terminal.
We are also getting a high resolution monochrome display for the server,
which will be located in an immediatley adjacent room. I would like to use
that display like a workstation. What I mean is that I would like to put a
getty on it which treats the display/kbd as an ANSI terminal. After login
a user could run a window system or not depending on his needs. This
display would not be used continually, so I am not greatly concerned about
its performance effect on the server. The area it will be in is only
medium security though, and it is important it not have any system console
function.
>From my reading of the manual, the ANSI terminal code is in the PROM and
is only available by a hook from the console device driver. It would seem
that I would need another device driver similar to the console driver that
calls the PROM code, and I would start a getty on its special device file.
Does anyone see another way to do it? I really don't want to restrict
it to suntools.
--
Ken Mandelberg | gatech!emory!km USENET
Emory University | km@emory CSNET,BITNET
Dept of Math and CS | km.emory@csnet-relay ARPANET
Atlanta, Ga 30322 | Phone: (404) 727-7963
------------------------------
Date: Mon, 27 Jul 87 14:10:23 EDT
From: rich%oxtrap.UUCP@umix.cc.umich.edu (K. Richard Magill)
Subject: disk drive questions
Sorry, if these are old hat, but I'm just looking at purchasing our
first suns.
1) How much disk space does a diskless sun 3/50 *really* need? Presume
for the moment that this 3/50 does *nothing* but terminal emulation all
day.
2) Who makes third party hard drives for suns?
K. Richard Magill
------------------------------
Date: Fri, 24 Jul 87 15:10:50 PDT
From: ultra!wayne@ames.arpa (Wayne Hathaway)
Subject: Query: third-party disk & tape drives?
We have a Sun 3/280 and are getting a Sun 3/160. Does anybody have any
recommendations on buying peripherals (tape and disk drives) from someone
other than Sun? We have no particular complaint about Sun products except
price: would it be worth doing some shopping around, or have others'
experiences generally been disasters? Thnx for any help.
Wayne Hathaway ultra!wayne@Ames.ARPA
Ultra Corporation
2140 Bering drive with a domain server:
San Jose, CA 95131 wayne@Ultra.COM
408-922-0100
------------------------------
Date: Sat, 25 Jul 87 15:37:36 PDT
From: tamir@cs.ucla.edu (Yuval Tamir)
Subject: dsun on SunView?
A long time ago somebody at Berkeley wrote a ditroff previewer for the
Sun, called dsun. The program was written for the old Suntools interface.
This old code does not compile properly on SunOS3.4 with Sunview. Many of
the data structures are not properly used, lots of warnings are generated,
and the program does not work.
Has anybody "ported" this code to run under Sunview?
Yuval Tamir
Internet: tamir@cs.ucla.edu
UUCP: ...!{ihnp4,ucbvax,sdcrdcf,trwspp,randvax,ism780}!ucla-cs!tamir
------------------------------
Date: Mon, 27 Jul 87 09:36 EST
From: RICHTER@gmr.com (Roy Richter)
Subject: Just another pretty icon
Since this list is getting into the icon-art business now, here is the
icon I use to tile my console, invoked with
suntools -pattern icon_as_described_below
/* Format_version=1, Width=64, Height=64, Depth=1, Valid_bits_per_item=16
*/
0xFFFF,0xFFFF,0xFFFF,0xFFFF,0x8FF0,0x0000,0x8000,0x00F8,
0x8E0F,0xF000,0x8001,0xFF88,0x89E0,0x0FF0,0x81FE,0x1E88,
0x88DE,0x000F,0xFE00,0xEC48,0x88B1,0xF001,0xE007,0x3448,
0x891E,0x0F01,0xE078,0xE244,0x912D,0x80F1,0xD383,0x5244,
0x9126,0x700F,0xDC0C,0x9124,0x924B,0x8C02,0xD831,0x8924,
0x9251,0x4386,0xD4C7,0x64A4,0x9290,0xB066,0xCF09,0x12A4,
0x92A1,0xCC1E,0xAB13,0xCA54,0x9546,0xA216,0xAB23,0x3F54,
0x9598,0x519A,0xAAC5,0x49D4,0xA6EF,0xC86A,0xA564,0xBA6A,
0xAB29,0x44AA,0xA55C,0xF26A,0xAE25,0x234A,0xA4AB,0x943A,
0xAD16,0xEE54,0xA496,0xD8DA,0xB8CF,0x3494,0xA491,0x390E,
0xB824,0x4894,0x9248,0x921E,0xB615,0x8924,0x9248,0x5C66,
0xB18A,0x1124,0x9224,0x3186,0xA066,0x2224,0x9222,0x2602,
0xF019,0x4224,0x9122,0xD807,0xCF06,0x8444,0x9111,0x6079,
0xC0F1,0x8444,0x9111,0x8781,0xC00E,0x6848,0x910E,0x3801,
0xFC01,0xF848,0x888B,0xC01F,0x83FE,0x1E88,0x88BC,0x3FE0,
0x8001,0xFF88,0x88FF,0xC000,0x8000,0x00F8,0x8F80,0x0000,
0xFFFF,0xFFFF,0xFFFF,0xFFFF,0x8000,0x07F8,0x8FF0,0x0000,
0x8007,0xF838,0x8E0F,0xF000,0x87F8,0x03C8,0x89E0,0x0FF0,
0xF800,0x3D88,0x88DE,0x000F,0xC007,0xC688,0x88B1,0xF001,
0xC078,0x3C48,0x890E,0x0F01,0xC780,0xDA44,0x9109,0x80F1,
0xF807,0x2244,0x9116,0x700F,0xA018,0x6124,0x9211,0x0C02,
0xB0E1,0xD124,0x9221,0xC386,0xB302,0x48A4,0x9226,0xA066,
0xBC0C,0x84A4,0x9248,0x501E,0xB411,0xE254,0x9493,0xEC0E,
0xAC22,0xDF54,0x94FC,0xD21A,0xAAC3,0x44B2,0xA589,0x519A,
0xAB05,0x246A,0xAB09,0x286A,0xA989,0x289A,0xAA86,0x24AA,
0x9549,0x711A,0xAC45,0xA754,0x94B3,0x920E,0xB422,0x7A54,
0x949E,0x2C1E,0xBC12,0x6494,0x9253,0x3066,0xB30D,0x84A4,
0x9248,0xE186,0xB0C2,0x08A4,0x9224,0x4602,0xA031,0x1124,
0x9222,0x9807,0xF00C,0xA124,0x9111,0x6079,0xCF03,0x4244,
0x9111,0x8781,0xC0F0,0xC244,0x890E,0x3801,0xC00E,0x3448,
0x890B,0xC01F,0xFC01,0xEC48,0x88BC,0x3FE0,0x83FE,0x1E88,
0x88FF,0xC000,0x8001,0xFF88,0x8F80,0x0000,0x8000,0x00F8
Roy Richter
GM Research Labs