Sun-Spots-Request@RICE.EDU (William LeFebvre) (08/31/88)
SUN-SPOTS DIGEST Tuesday, 30 August 1988 Volume 6 : Issue 208
Today's Topics:
Re: Speeding up dumps over the network (2)
Re: pcnfs and sun networks
get_socket: UNIX buffered is 0- An answer
screenblank and Netnews software
YP vs. /etc/group
netmask foo
Bomb *dbx(SunView)
Problems with NIT networking interface
sa -m not working on 3/50
386i as machine controller?
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: Sun, 28 Aug 88 13:51:00 N
From: Sven-Ove Westberg <enea!eru.mt.luth.se!sow@uunet.uu.net>
Subject: Re: Speeding up dumps over the network (1)
> About speeding up dumps over the network: rmt uses the least efficient
> possible method (read a block, send a block, write a block to tape, send
> back acknowledgement, start over)...
Between which type of systems is the tests done? It exists a well known
performance hog if you dump from a system that did not increase its
tcpsendspace when dumping to a 4.3 system.
Later I will try to modify the /etc/rmt similar to the posted ddd program.
I have tested 4.3 dump with different tcpsendspaces on a sun to a 4.3bsd
vax750 and found that you have to increase the tcpsendspace to 16k.
This is the figures I got. I used a Sun/160 and a vax 11/750 with a TU77,
local dump on the sun the streamer tape.
Blocksize is the b parametr from dump manualpage. NOTE it is a bug in Sun
dump it uses 512bytes block instead of 1024 bytes. This explains the odd
figure 15 for the Sun. (I am lazy so I didnt redo all the tests)
Local dump (to the streamer on Sun)
Program Block size 10 20 30 126
Sun dump * * * 26 kb/sek
4.3 dump. * * * 59
Remote dump tcp_sendspace 4k (default sendspace from sun to vax)
Program Block size 10 15 20 30 126
Sun rdump 39 22 * * * kb/sek
4.3 rdump 51 * 32 * *
Remote dump tcp_sendspace 8k
Program Block size 10 20 30 126
Sun rdump * * * * kb/sek
4.3 rdump 57 58 37 *
Remote dump tcp_sendspace 16k
Program Block size 10 20 30 126
Sun rdump 41 * 43 * kb/sek
4.3 rdump 57 67 72 *
Compare this with that a local dump on the vax archives 80-90 kb/sec and a
remote dump from one between to bsd4.3 11/750 vaxes gives 49kb/sec.
On a 3.x sun you can change the tcp_sendspace in the kernel the folowing
way. Run the script below and to a shutdown, fastboot.
#!/bin/sh
SPACE=4000
QUIT=\$q
adb -w -k /vmunix /dev/kmem << EOADB
tcp_sendspace?W$SPACE
$QUIT
EOADB
You will run into this preformace hog with all programs that use a large
tape blocksize when you use a remote tape on a 4.3bsd system. Since rmt in
4.3 sets the tcp_receivespace related to the receive blocksize.
NOTE that the performance decrease if the block size in increased on a
unchanged System.
I think that sun has included TB_SIZE in setsockopt in 4.0. But it is
important that ALL rtape programs use this option also!!
Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden.
Internet: sow@cad.luth.se
------------------------------
Date: Mon, 29 Aug 88 09:42:10 EDT
From: zwicky@pterodactyl.cis.ohio-state.edu (Elizabeth D. Zwicky)
Subject: Re: Speeding up dumps over the network (2)
All the systems involved are Suns. (We do also dump to a Pyramid, but all
the numbers I quoted were between Suns.) The effect is entirely dependent
on network delay; speeding up the gateways decreased dump time by a factor
of 6.
EDZ
------------------------------
Date: Sun, 28 Aug 88 23:38 EST
From: BEAME%SSCvax.McMaster.CA@cornellc.ccs.cornell.edu
Subject: Re: pcnfs and sun networks
monty%tartarus@gargoyle.uchicago.edu writes :
> ... we were, as are many pc-nfs users, disappointed that
> pc-nfs recognized only the primary groups with users (the group in the
> /etc/passwd file, but none of the groups in the /etc/group file).
The new product BWNFS which I mentioned in Sun-Spots before allows for up
to 16 groups (8 if your running Sun OS 3.x). The user is also able to
change his primary group to any of the 16 groups. (We currently don't
allow changing to the 17th or above group).
> we were also disappointed (and surprized) that pc-nfs offered no
> method to either determine which pc users are on the system or to send
> broadcast messages to pc users (so that they can be warned of system
> shutdowns or other such non- trivial details).
We currently don't have either of these two features, but we are on the
look out for any good suggestions on what is need in a PC NFS type
product. Send any ideas to:
Beame@McMaster.CA
-Carl Beame
------------------------------
Date: Mon, 29 Aug 88 11:07:32 PDT
From: Jonathan Eisenhamer <jon@mira.astro.ucla.edu>
Subject: get_socket: UNIX buffered is 0- An answer
To all Spots,
I recently posted a question on what
get_socket: UNIX buffered is 0
means, assuming that it was generated by the kernel. Well, it is a
message from a local program indicating a status. Fortunately, the
original author reads this newsgroup and clarified everything. Sorry for
confusing the heck out of everyone.
Jonathan Eisenhamer
------------------------------
Date: Mon, 29 Aug 88 08:23:18 edt
From: mlijews@nswc-wo.arpa
Subject: screenblank and Netnews software
Spots,
There is another problem with screenblank which I haven't seen discussed
in this list. Many of my users invoke screenblank from their .login
files. This causes a problem when rlogin'g into other machines since
screenblank doesn't check to see if it is already running on that machine.
So with people actively rlogin'g into other machines I have seen as many
as 8 screenblanks running on the same machine. Certainly, there is no
need for more than one screenblank per machine! Below is a /bin/sh
wrapper I wrote to help solve this problem. It works fine, except that it
is quite slow due to the ps. If anyone has solved this problem in a more
elegant way, please tell me about it.
Also, can anyone tell me how to get a current version of the Netnews
software for running on a Sun-3/180?
Mike
#! /bin/sh
#
# @(#) screenblank.wrap Version 1.1
#
# This is a wrapper program for /usr/bin/screenblank.
# To install:
#
# mv /usr/bin/screenblank /usr/bin/screenblank.exec
# cp screenblank.wrap /usr/bin/screenblank
#
tmp1=/tmp/screenblank.$$.1
tmp2=/tmp/screenblank.$$.2
trap "/bin/rm -f $tmp1 $tmp2" 0 1 2 15
/bin/ps ax > $tmp1
/usr/bin/egrep screenblank.exec $tmp1 > $tmp2
if [ ! -s $tmp2 ]; then
echo screenblank started...
/usr/bin/screenblank.exec
else
echo screenblank is already running...
fi
------------------------------
Date: Mon, 29 Aug 88 10:30:21 CDT
From: natinst!brian@cs.utexas.edu (Brian H. Powell)
Subject: YP vs. /etc/group
I had a user come to me today to complain that he couldn't read a file he
used to be able to read. I checked the permissions on the file and the
directories in the path to that file. Everything was okay. I checked
/etc/group. He was in the proper group. I did "groups user" (where
"user" was the login of the person with the problem), and all the groups
he was supposed to be in appeared. Then I did "su user" and "groups", and
not all of the groups appeared.
The problem, evidently, is that YP doesn't deal with group entries that
consist of more than one line. For example,
group1:*:50:brian,foo,foo2
group1:*:50:lulamae,jimbob,marylou
The users brian, foo and foo2 will actually be assigned to the group1
group. The users lulamae, jimbob and marylou will not.
I wonder if this relates in any way to my earlier problem, where
gethostbyname doesn't really work right if YP is running...
------------------------------
Date: Sat, 27 Aug 88 19:14:53 PDT
From: Craig Leres <leres@helios.ee.lbl.gov>
Subject: netmask foo
Earlier this month, Darin Johnson complained about not being able to boot
a diskless client after adding an explicit "netmask 0xffffff00" to the
ifconfig line in rc.boot. He said he was running 3.4.
This problem is probably similar to one I just solved. Another guy has a
sun4 file server running 3.2 and a bunch of diskless clients running 3.5.
The difficulty was the same; he wanted to use a netmask of 0xffffff00 on
the clients but couldn't boot them if he did.
What's wrong here is that when you set the subnet mask, the broadcast
address gets set as a side effect. In 3.5, the interface address is ANDed
with the netmask. For example, ifconfiging to 128.3.254.160 with a netmask
of 0xffffff00 results in a broadcast address of 128.3.254.0.
Unfortunately, the 3.2 file server doesn't recognize this as a broadcast
address and so ignores client packets with this broadcast address.
The workaround we came up with was to explicitly set the broadcast address
like so:
ifconfig ie0 128.3.254.160 -trailers netmask 0xffffff00 \
broadcast 128.3.0.0
This isn't too bad of a kludge since systems that understand subnets
usually recognize all possible broadcast addresses.
Craig
------------------------------
Date: Sun, 28 Aug 88 20:59:31 PDT
From: chaos@gojira.Berkeley.edu
Subject: Bomb *dbx(SunView)
The following code bombs dbx, although it runs fine by itself. (Don't ask
how long it took to distill this.) I have the nagging feeling I am missing
something.
Comments appreciated.
/* bug.c: dbx bombs on this */
/* Although it runs fine by itself */
/* Take the scanf out and dbx runs fine */
/* Environments tested: */
/* SunOS 3.2 on a Sun 3/50 */
/* SunOS 3.2 on a Sun 3/60 (with 3.5 kernel) */
/* Compile: cc bug.c -o bug -lsuntool -lsunwindow -lpixrect -g */
/* dbx error message:
signal TTIN (stop (tty input)) in syscall at 0x564fe
syscall+0xa: trap #0x0
*/
#include <stdio.h>
#include <suntool/sunview.h>
main()
{
int i;
Frame BaseFrame;
BaseFrame = window_create(0,FRAME,0);
printf("Type an int ");
scanf("%d",&i);
}
Jim Crutchfield
Physics, UCB
------------------------------
Date: Mon, 29 Aug 88 09:18:04 MDT
From: cyrus@hi.unm.edu (Tait Cyrus)
Subject: Problems with NIT networking interface
Recently we upgraded to SunOS 4.0 and I have been attempting to rewrite
some programs that use the nit interface. After much rigamarole, I was
able to get "something" to work.
I have two problems that I can't see to be able to solve though:
1) nit appears to return garbage to me sending my program off into
never-never land. By default, nit returns the ethernet packet
prepended with a 2 u_int header. The 1st u_int is the "msglen"
(supposed to be the amount of data returned to the user) and the 2nd
u_int is the "totlen" (supposed to be the total length, in bytes,
from the start of this nit header to the start of the next).
What is happening, occasionally, is that the "totlen" returns as
garbage (either a VERY large number or zero). What does it mean
when this happens? Do I just ignore the rest of the data returned
in this read and try to get back in sink with the next read? Is
this an indication that the SunOS had problems allocating enough
buffers? Is there a way around it???????
2) I can't seem to be able to specify the snap length (the maximum
amount of data from packets that gets returned via the read). If I
specify zero (0), the entire packet gets returned just like the man
page says it will. It is my understanding that if I use a snap
length of 64, then I will at least get 64 bytes of data assuming
the incoming ethernet packet was >= 64. If the ethernet packet
is >= 60 and < 64 (snaplen), then I should get the entire ethernet
packet.
If I specify a snaplen of 64 and the ethernet packet is <= 64 (yes
less than AND equal to), nit only returns only 16 bytes (as far as I
can tell) which is real strange since the "msglen" is 22 and the
"totlen" is 32. The 32 looks correct, but the 22 (22=14+8 for
headers) looks incorrect; I am getting 16 bytes not 14. If the
ethernet packet length is > 64 (greater than), then indeed I
only get 64 bytes returned.
What is going on????? I should ALWAYS be returned the ENTIRE packet if
it's length is <= snaplen but I am not. Am I interpreting the man page
incorrectly?? Is the "normal"????
W. Tait Cyrus (505) 277-0806
University of New Mexico
Dept of EECE - Hypercube Project
Albuquerque, New Mexico 87131
e-mail:
cyrus@hi.unm.edu
or cyrus%hi.unm.edu@ariel.unm.edu
------------------------------
Date: Mon, 29 Aug 88 11:08:13 PDT
From: Jonathan Eisenhamer <jon@mira.astro.ucla.edu>
Subject: sa -m not working on 3/50
It has been decided that simple accounting needs to be done on our sun
systems. Basically all that is needed it the result of /usr/etc/sa -m.
This works fine on the 3/260 server and 3/160 client, but on all three of
our 3/50's, it fails with segmentation violation. Examining the shell
variable status, it contains the number 139. All the other options to sa
work, just sa -m fails. We are running SunOS 3.4.
Has anyone seen this? Are there any suggestions?
Thank you for your time,
Jonathan Eisenhamer
mira.astro.ucla.edu (128.97.64.198)
jon@uclastro.bitnet
bonnie::jon (span 5.708)
(213)206-8596
------------------------------
Date: Mon, 29 Aug 88 08:44:13 EDT
From: Dave Shaver <@ll-vlsi.arpa:shaver@ll-micro>
Subject: 386i as machine controller?
I'm interested in using a Sun-386i as a 'machine controller'. That is, I
want to access boards like A/Ds, D/As, DIOs, and TV Framegrabbers. The
386i is attractive because there are oodles of CHEAP PC-compatible boards,
and because I can ultimately move some of the boards to PC's.
I have done similar things in the past using VME-based 3/160's and
3/110's. I relied heavily on the 'mmap hack'; this is the ability to map
VME bus addresses directly into user virtual-address space, allowing I/O
from a user task. The 386i does allow mapping of the atbus memory space,
but I/O space must be accessed directly by the 80386's IN and OUT
instructions--- thus, one can't MMAP I/O space! (Hmmm).
A look at 80386 information revealed no fundamental reason why a user task
can't do IN and OUT instructions. If the IOPL is set to a high enough
value, the user task can do I/O free of restrictions. Alternatively, with
a lower IOPL, the port bitmap can be set to allow a user task access to
IN/OUT instructions on specified ports in I/O space.
A quick experiment at my local sales office revealed that a UNIX user task
will pull a segmentation fault if an IN instruction is put in-line. Why
not allow IN/OUT from Unix processes? Since DOS windows can do direct bus
accesses, it seems hard to argue that this would create a gaping security
hole (it's already there). And, for things like A/D's, D/A's, etc... the
Unix device driver interface isn't exactly the most clean (or efficient)
setup!
I've posted this because I'm hoping someone may have faced this or that
someone at Sun might consider doing something--- this will come up again!
Some solutions:
(a) Give Unix tasks an I/O bitmap which allows access to some
large chunk of I/O space not used by Sun's favorite devices.
(b) Provide a system call which allows a Unix task to 'enable'
I/O to a range of ports.
(c) Give Unix tasks the same default I/O slots permitted to
DOS tasks by the "boards" file (this sounds pretty clean?).
Maybe one of these things already exists and we just haven't found it yet!
Dave Shaver
MIT Lincoln Laboratory
244 Wood St.
Lexington, MA 02173
(617)-981-0956
shaver@ll-vlsi.arpa
------------------------------
End of SUN-Spots Digest
***********************