HDTenEightyP/NetNews huggingface dataset:
From: wb@arb-phys.uni-dortmund.de (Wilhelm B. Kloke)
Subject: Re: Is local caching configurable?
Organization: Institut f. Arbeitsphysiologie a.d. Uni Dortmund
Date: Tue, 10 Nov 92 07:11:09 GMT

In article <776@sandia.UUCP> kristina@sandia.uucp (Kristina Buchholtz (9226)) writes:
>I'm using Ultrix 4.3, and have done some timing tests on
>local disk access vs. nfs disk access.  Nfs seems to be
>about twice as fast on writes of large files, and I am
This is quite normal, the data are cached three times when writing on NFS;
first normal Unix write cache; second the NFS server process and third
the write cache on the server.
>guessing this is because the data is cached.  Are there
>some parameters that can be tweaked to cause local data
>to be cached, to make local accesses as fast as nfs
They are always cached except when written synchronously.
>accesses?  (If so, would this be a bad idea?)  (I realize
>this nfs vs. local timing difference is not limited to
>Ultrix 4.3; I've found the same results on Ultrix 4.2 and
>SunOS.)
Of course you pay for the better write performance via NFS by loading
the server and using up it's memory. You may speed up your local write
access by adding more memory (bigger buffer pool) to your machine.
-- 
Dipl.-Math. Wilhelm Bernhard Kloke,
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-4600 Dortmund 1, Tel. 0231-1084-257
Newsgroups: comp.unix.ultrix
From: rog@Ingres.COM (Roger Taranto)
Subject: BUFCACHE statistics on a VAX 3600
Organization: Ingres Corporation
Date: 6 Nov 92 21:12:22 GMT

How do I obtain the hit rate, etc, for
the BUFCACHE on a VAX 3600 running 4.2?

Thanks,
-Roger
rog@ingres.com
Newsgroups: comp.unix.ultrix
From: mjr@hussar.dco.dec.com (Marcus J. Ranum)
Subject: Re: SUMMARY:  disk I/O slowdown with Ultrix 4.3
Organization: Digital Equipment Corporation, Washington ULTRIX Resource Center
Date: Mon, 9 Nov 1992 16:01:41 GMT

metcalf@CATFISH.LCS.MIT.EDU (Chris Metcalf) writes:
>> Why do I *lose* performance with maxcontig = 8 in some configurations?
>
>The configuration in question was the RZ56.  Following up on a suggestion
>from Marcus Ranum, I tried testing the disk using "time dd" and various
>different blocksizes on the raw disk devices.

	Mea culpa. I was parrotting something that the fellow in charge
of the group that did the I/O enhancement stuff had said was a good
set of parameters to use. I either remembered wrong, or had a value
for the '56 that was out of whack.

	One interesting note about the I/O enhancer stuff that everyone
should be aware of: it now makes fragmentation a possible issue for
ULTRIX. Now we need to worry about defragging our disks every so often.
I don't really know (though I'm trying to find out) how to tell if a
disk is getting fragged (other than that it slows down) and right now
there's no known tools for defragging a disk other than dump, newfs,
and restore. I figure I'm just not going to worry about it on my
systems. ;)

	I believe that since the I/O enhancement stuff attempts to
lay files down in longer patches, there's a good chance that a
performance benefit will be realized if you reload system disks
that have binaries on them, so they'll be laid out nicely - especially
if there's enough free space on the disk that you can lay all those
big fat X-windows tracks down without having to fragment them. ;)
I haven't had time to try this, so *DON'T* take my word for it and
hose your machine, unless you're very, very bored...

mjr.
Newsgroups: comp.unix.ultrix
From: giltner@pogo.Colorado.EDU (Jon Giltner)
Subject: Re: 3 peeves re: Ultrix 4.3
Organization: University of Colorado, Boulder
Date: Fri, 6 Nov 1992 16:03:17 GMT

ajc@pa.dec.com (AJ Casamento) writes:

>  We've had great success with this effort. I've gotten a number of written
>statements from SCSI peripheral vendors saying how easy it is to port to the
>DEC SCSI CAM implementation (and I didn't even solicit them...in fact, one guy
>stood up in a customer seminar in France and just gushed for 10 minutes about
>it...not that I minded). It means that non-storage devices don't have to play
>at being tape drives any more. It means that as other vendors complete their
>CAM implementations you'll get closer and closer to the "plug-n-play" world you
>originally thought you had when you bought SCSI. It also means a much easier 
>time for DEC in terms of adding new SCSI products and qualifying them. 

>  SCSI CAM is worth it.

Amidst the gushing there are those of who still must ask why DEC is so
braindead about their SCSI. Strictly from a user's point of view, I don't
see any difference between having to edit the very cryptic /sys/data/cam_data.c
to define a new disk or tape device vs. editing /sys/data/scsi_data.c file.
And to top it off, as for "plug-and-play", what's the logic behind having
the predefined Exabyte Exb-8500 entry in cam_data.c key on the drive
identifying itself as a "DEC TKZ09" instead of "EXABYTE EXB-8500"? SCSI CAM
really did nothing to facilitate plug-and-play SCSI on Ultrix.


Jon
-- 
Jon Giltner
Computing and Network Services          University of Colorado 
(giltner@spot.Colorado.EDU)             Boulder
Newsgroups: comp.unix.ultrix
From: mcrowley@MtHolyoke.edu (Michael A. Crowley)
Subject: lockd and pathworks
Organization: Mount Holyoke College
X-Newsreader: Tin 1.1 PL5
Date: Tue, 10 Nov 1992 03:13:59 GMT

On a 5000/240, 4.2a, we have NFS locking set up and Pathworks 1.11
(and 1.20) set for "yes", do both Ultrix and pathworks locking.  This machine
has a file system or two shared to a dozen or so lightly used machines.

Recently there have been three occasions when accessing a file
on a local file system with pathworks, the pathworks server 
has apparently stopped functioning and lockd began to eat 
a tremendous amount of time.  The PC trying to access the file
was hung up, and shutting it off it did not affect the amount
of time lockd was eating.  On one occasion, the pcsafs processes
and the pcsaadmd process could not be killed, even with a 9.
They wouldn't die.  The other times we managed to "pcsa stop"
and they did die off, though lockd kept eating time.

Unfortunately nothing obvious has changed and this has been a
configuration we've been running since this summer with no
problem.  We upgraded the server from 1.11 to 1.20 after the
first instance.  Has anyone encountered something like this?

Michael Crowley, Mount Holyoke College, mcrowley@mtholyoke.edu
From: thomas@lkg.dec.com (Matt Thomas)
Newsgroups: comp.unix.ultrix
Subject: Re: Can't make enough inodes
Date: 7 Nov 92 01:40:00 GMT
Article-I.D.: nntpd.1992Nov7.014000.10694
Reply-To: thomas@lkg.dec.com
Organization: Digital Equipment Corporation


In article <1desisINNdas@cat.cis.Brown.EDU>, JIM@brownvm.brown.edu (James Mathiesen) writes:
|>We have a DEC RISC machine running Ultrix 4.2a -- Rev 47.
|>Among other things this is being used for netnews and has a couple
|>of 1.3gig disks for that purpose.  The problem I'm having is there
|>are way to few inodes in the filesystems of these disks.  The documentation
|>says the default is an inode per 2k.  These disks have an inode per 4k.
|>My best guess is the disks will run out of inodes when they are 65% full.
|>
|>Here's the newfs command I tried:
|>
|>  # newfs -v -i 512 /dev/rrz5g RZ58
|>  Warning: partition table overriding /etc/disktab
|>  /etc/mkfs /dev/rrz5g 1878860 85 15 8192 1024 16 10 60 512 t
|>  Warning: 502 sector(s) in last cylinder unallocated
|>  /dev/rrz5g:     1878848 sectors in 1474 cylinders of 15 tracks, 85 sectors
|>          962.0Mb in 93 cyl groups (16 c/g, 10.44Mb/g, 2048 i/g)
|>
|>But that just builds the same old filesystem with the same number of
|>inodes.  Passing various -i parameters leads me to believe that mkfs
|>is ignoring the value completely.
|>
|>I can't find anything useful in the man pages for mkfs, newfs, or chpt.
|>Does anyone have any suggestions?  Partitioning the disk further
|>won't help, at least not as long as the ratio of inodes stays the
|>same.

The easiet way it to lower the number of cylinders per group (-c 8) and 
reduce the block/frag to 4096/512 (-b 4096 -f 512).  Here's what I have for
my news server: 

Filesystem   Total    kbytes   kbytes   %     inodes   inodes   %
node         kbytes   used     free     used  used     free     used Mounted on
/dev/ds0a    2008950 1735109   72946    96%   596322   77470    89%  /usr/spool/news

--
Matt Thomas                     Internet:   thomas@lkg.dec.com
DECnet-ULTRIX Development       UUCP:       ...!decwrl!thomas
Digital Equipment Corporation   Disclaimer: This message reflects my own
Littleton, MA                               warped views, etc.
Newsgroups: comp.unix.ultrix
From: ajc@pa.dec.com (AJ Casamento)
Subject: Re: scsi disk for Decstations
Organization: Digital Equipment Corporation
Date: 10 Nov 92 12:39:27




In article <1992Nov6.150906.70@cc.uab.es> ccpaz@cc.uab.es writes:


>> Sorry for a too basic question.
>> We want to add an external disk to our Decstation 5200, my question is
>> do i have to limit my search inside digital or are there third party scsci 
>> disk suppliers compatible with Decstations?
>> And how can i know the compatibility of the different vendor's disks with 
>> the machine?
>> For example can i by an IBM scsci disk and plug it into a Decstation?
>> I am looking for at least 2Gb , but for what i've seen i should by 2 disk of
>> 1Gb each, does it exists a 2Gb or bigger external disk?

>>  M.Paz Alvarez
>> Computer Center
>> Universitat Autonoma Barcelona
>> Bellaterra (Barcelona)
>> Spain

Senor Alvarez,

  Actually, it's not such a basic question. There are a number of problems that
you can avoid by asking your disk drive vendor a couple simple questions:

  1. Does the vendor have a SCSI-2 compliant firmware? (Or, does the vendor 
     have a DEC firmware variant). There are some vendors who have disks that
     do not respond to a SCSI bus reset within 500 milliseconds and this can
     cause the disk drive not to be recognized.

  2. Does the vendor's synchronous SCSI device allow for synchronous transfer
     to be negotiated (per the ANSI SCSI-2 specification) or is it hard-wired
     with a jumper? The DEC console firmware deals with the drive in asynch
     mode and will then attempt to negotiate synchronous when the OS boots.


Also, if you intend to use a disk drive which formats to a larger than a 1.0GB 
size, you will need to be running Ultrix v4.2 or higher. If you are going to be
looking at using SCSI based printers, scanners or communications hardware you
may want to install the CAM SCSI subsets (they will become the default in the
future).

  I've had a chance to see/work with disk drives from Seagate, Micropolis, 
Clearpoint, Maxtor and Hitachi. I've heard only good things about HP and IBM
drives as well but I've not had any direct work contact with them. I've got no
particular attachment to any of the above vendors (I'm not connected with them
and I receive no money for my opinions) I'm just trying to answer your inquiry
about disk drives.

I hope that helps.

				Thanx,
				  AJ


      **********************************************************************
      * AJ Casamento			"The question is not whether or    *
      * Digital's TRI/ADD Program	 not the opinions are mine; but    *
      * 529 Bryant Ave. PAG-2		 rather, which of my personalities *
      * Palo Alto, CA 94301-1616	 do they belong to?"		   *
      * 415.617.3460							   *
      * ajc@pa.dec.com  						   *
      **********************************************************************
Newsgroups: comp.unix.ultrix
From: john@iastate.edu (John Hascall)
Subject: Re: Need package to track CPU usage
Organization: Iowa State University, Ames, IA
Date: Fri, 13 Nov 1992 02:39:22 GMT

barrett@iastate.edu (Marc N. Barrett) writes:
}   Is there a program available for Ultrix 4.2 that will help in keeping track
}of the CPU usage by various users?  The accounting utilities provided with
}Ultrix seem to only be able to log the amount of time that users are logged
}in, and I would like to be able to log the amount of actual CPU time used as
}well. 

   Right in The Fine Manual:

      man 8 sa

John
-- 
John Hascall                   ``An ill-chosen word is the fool's messenger.''
Systems Software Engineer
Project Vincent
Iowa State University Computation Center  +  Ames, IA  50011  +  515/294-9551
Xref: sparky comp.unix.ultrix:8222 comp.sys.dec:5875 comp.org.decus:973
From: chernoff@sousa.tay.dec.com (Anton Chernoff)
Newsgroups: comp.unix.ultrix,comp.sys.dec,comp.org.decus
Subject: Re: What are the variables %U, %J in /etc/printcap (Ultrix 4.2) ?
Date: 10 Nov 92 21:47:33 GMT
Reply-To: chernoff@sousa.tay.dec.com (Anton Chernoff)
Followup-To: comp.unix.ultrix
Organization: Digital Equipment Corporation


In article <1992Nov3.180943.5277@news.uni-stuttgart.de>, wnkretz@ikesg1.energietechnik.uni-stuttgart.de (Oliver Kretzschmar) writes:
|>    I want to know, what the following parameters in /etc/printcap means.
|>    The parameters I want to know, are in the command line :  
|>    
|>	of=/usr/lib/lpdfilters/iplpscomm %U %J
|>
|>    Could somebody tell me what the parameters %U, %J and so on means ?
The %U is the user's login name; the %J is the job id as shown by lpq.
All these and more are documented in the man page for lpd(8).
--
Anton Chernoff (chernoff@tallis.enet.dec.com)

Simple awareness is often curative.

Newsgroups: comp.unix.ultrix
From: rince@dcs.warwick.ac.uk (James Bonfield)
Subject: Re: CD-ROM is really a pseudoterminal??
Keywords: Gak!  Ugh!  Pfui!
Organization: Department of Computer Science, Warwick University, England
Date: Thu, 12 Nov 1992 10:15:38 GMT

In <5435@daily-planet.concordia.ca> smw@alcor.concordia.ca ( Steven Winikoff ) writes:

>     crw-rw-rw-  1 root     system    21,  42 Nov 11 17:28 /dev/ptyra
>     brw-------  1 root     system    21,  42 Jun  9 17:45 /dev/rz5c
> 
> WHAT'S GOING ON HERE?

Things are the same on the system I use - however, note that ptyra is a
character device and rz5c is a block device. My guess is that the two do not
cause any conflicts. Is this right?

James Bonfield (jkb@mrc-lmba.cam.ac.uk)   Tel: 0223 402499   Fax: 0223 412282
Medical Research Council Laboratory of Molecular Biology,
Hills Road, Cambridge, CB2 2QH, England.
-- 
James 'Rince' Bonfield             O    .__   ._ ~ ~    /\/ ~        /\/
jkb@mrc-lmba.cam.ac.uk              o  /o  \_/ /        \/\  /o\/    \/\   ~
rince@dcs.warwick.ac.uk               (     | (  ~ ~         \(/\            ~
csuba@csv.warwick.ac.uk                \/__/ \_\                  ~
From: maklinm@cognos.com (Max Maklin)
Newsgroups: comp.unix.ultrix
Subject: Re: SUMMARY:  disk I/O slowdown with Ultrix 4.3
Date: 10 Nov 92 03:14:27 GMT
Article-I.D.: cognos.1992Nov10.031427.25982
Organization: Cognos Incorporated, Ottawa CANADA

In article <1992Nov9.160141.18573@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes:
:^()  
:^()  	Mea culpa. I was parrotting something that the fellow in charge
:^()  of the group that did the I/O enhancement stuff had said was a good
:^()  set of parameters to use. I either remembered wrong, or had a value
:^()  for the '56 that was out of whack.

It would be interesting Marcus if you get the fellow in charge to take a
number of "typical" systems, and typical disks and let us know what the
best parameters are.  I am not in the postition to play with my disks (R&D
environment), but given a set of parameters and would take the time to
dump, newfs, tunefs, restore to get the better performance.  If anyone has
the numbers for a 5500, asc controller and RZ57 and RZ58 disks, I'll take
them :)

:^()  
:^()  	One interesting note about the I/O enhancer stuff that everyone
:^()  should be aware of: it now makes fragmentation a possible issue for
:^()  ULTRIX. Now we need to worry about defragging our disks every so often.
:^()  I don't really know (though I'm trying to find out) how to tell if a
:^()  disk is getting fragged (other than that it slows down) and right now
:^()  there's no known tools for defragging a disk other than dump, newfs,
:^()  and restore. I figure I'm just not going to worry about it on my
:^()  systems. ;)
:^()  

For us that have been running 4.2 filesystems from Sun and hfs from HP
and  others this is nothing new.  I usually do it once or twice a year
to each disk.

Max
-- 
Max Maklin                                                P.O. Box 9707 
Technical Analyst	                           3755 Riverside Drive
Cognos Incorporated                              Ottawa, Ontario CANADA
Internet: maklinm@cognos.COM                 UUNet: maklinm@cognos.UUCP
Newsgroups: comp.unix.ultrix
From: ljuno@zeus.bram.cdx.mot.com (Lance Juno)
Subject: 4.3 upgrade on 2100's and 3100's
Keywords: 4.3, memory, upgrade
Reply-To: ljuno@zeus.bram.cdx.mot.com (Lance Juno)
Organization: Motorola Codex, Mississauga, Ontario
Date: Mon, 9 Nov 1992 18:28:21 GMT

We have a collection of 2100's and 3100's all running Ultrix 4.1 and
configured with 12 Mb RAM.  Obviously we are considering upgrading to
4.3, but first I have a couple of questions.

Does anyone have any feel for the amount of RAM required in 2100/3100
nodes for 4.3 ?  I've heard that these nodes should be configured with
24 Mb RAM - any comment on this ?

If I get enough email, I'll summarize.

Lance

--
[ Lance Juno                              |  Motorola Codex                  ]
[ Internet: ljuno@dnbf01.bram.cdx.mot.com |  400 Matheson Blvd. West,        ]
[ Phone:        +1 416 507 7200           |  Mississauga, Ontario   L5R 3M1  ]
[ Fax:          +1 416 507 7236           |  Canada                          ]
Newsgroups: comp.unix.ultrix
From: smw@alcor.concordia.ca ( Steven Winikoff )
Subject: Re: CD-ROM is really a pseudoterminal??
Keywords: Gak!  Ugh!  Pfui!
Organization: Concordia University, Montreal, Quebec
Date: Thu, 12 Nov 1992 19:45:14 GMT

In article <1992Nov12.101538.6058@dcs.warwick.ac.uk>, rince@dcs.warwick.ac.uk (James Bonfield) writes:
> In <5435@daily-planet.concordia.ca> smw@alcor.concordia.ca ( Steven Winikoff ) writes:
> 
> >     crw-rw-rw-  1 root     system    21,  42 Nov 11 17:28 /dev/ptyra
> >     brw-------  1 root     system    21,  42 Jun  9 17:45 /dev/rz5c
> > 
> > WHAT'S GOING ON HERE?
> 
> Things are the same on the system I use - however, note that ptyra is a
> character device and rz5c is a block device. My guess is that the two do not
> cause any conflicts. Is this right?

I did notice that one is a block device and one is a character device.
However, pff obviously thinks they're equivalent.  Also, while I'm
definitely no kernel hacker, I *thought* I understood that the major
and minor numbers are all that the kernel actually uses to identify
a device.  Aren't these numbers used to index a table of pointers to
device driver routines?  If so, the combination (21,42) should invoke
the same driver.

In any case, mount does report that the device is busy, and no other
processes seem to be involved, other than a telnet on /dev/ptyra.

I *don't* really know what's going on.  That's why I'm hoping someone
who does will help!

    - Steven
________________________________________________________________________
Steven Winikoff      |       smw@         | "I don't want to run the
Software Analyst     | alcor.concordia.ca | world; I merely want to own
Computing Services   |                    | a substantial portion of the
Concordia University | (514) 848-7619     | preferred stock" - Alan Dean
Montreal, QC, Canada | (10:00-18:00 EST)  | Foster,  Cat-A-Lyst
From: ajc@pa.dec.com (AJ Casamento)
Newsgroups: comp.unix.ultrix
Subject: Re: 3 peeves re: Ultrix 4.3
Date: 5 Nov 92 15:51:36 GMT
Article-I.D.: thendara.AJC.92Nov5075136
Organization: Digital Equipment Corporation





In article <ggm.720916451@brolga> ggm@brolga.cc.uq.oz.au (George Michaelson) 
writes:



>> (1)	Can somebody from DEC please state what advantages lie in using
>>	   SCSI/CAM:
>>		   speed.
>>		   size of kernel.
>>		   future growth.
>>		   correctness.

>>	   Apart from the buzzwords like "industry standard" in the docs, I 
>>	   can see NOTHING which states "run SCSI/CAM and your disks will melt
>>	   the I/O is so fast" or other "useful motivating factors"


>>Remainder of post deleted<<

>> -George
>> --
>>			    George Michaelson
>> G.Michaelson@cc.uq.oz.au The Prentice Centre      | There's no  market for
>>			    University of Queensland | hippos in Philadelphia
>> Phone: +61 7 365 4079    QLD Australia 4072       |          -Bertold Brecht



George,

  The basic issue around CAM has to do with people wanting to acheive what they
thought they were originally getting with SCSI, compatibility. The difficulty
with the ANSI SCSI standard is that it is a wire protocol. And a wire protocol
that grew up over a long period of time (from Alan Shugart's SSI, to ANSI SCSI
version 1, to the Common Command Set draft, to ANSI SCSI version 2) with a lot
of baggage and grandfathering (grandparenting?) of code that protected old and
non-standard implementations.

  The CAM (Common Access Method) committee was some 20 or more companies who
all agreed that this software interface needed standardization. This included
support for non-storage devices (printers, scanners, etc.). 

  We've had great success with this effort. I've gotten a number of written
statements from SCSI peripheral vendors saying how easy it is to port to the
DEC SCSI CAM implementation (and I didn't even solicit them...in fact, one guy
stood up in a customer seminar in France and just gushed for 10 minutes about
it...not that I minded). It means that non-storage devices don't have to play
at being tape drives any more. It means that as other vendors complete their
CAM implementations you'll get closer and closer to the "plug-n-play" world you
originally thought you had when you bought SCSI. It also means a much easier 
time for DEC in terms of adding new SCSI products and qualifying them. 

  SCSI CAM is worth it.


I hope that clears it up for you.

				Thanx,
				  AJ


      **********************************************************************
      * AJ Casamento			"The question is not whether or    *
      * Digital's TRI/ADD Program	 not the opinions are mine; but    *
      * 529 Bryant Ave. PAG-2		 rather, which of my personalities *
      * Palo Alto, CA 94301-1616	 do they belong to?"		   *
      * 415.617.3460							   *
      * ajc@pa.dec.com  						   *
      **********************************************************************
Newsgroups: comp.unix.ultrix,comp.sys.dec
From: hirai@cc.swarthmore.edu (Eiji Hirai)
Subject: Re: Exists there filters to print ASCII-files on HP Postscript Printer - Need Info
Organization: Information Services, Swarthmore College, Swarthmore, PA, USA
Date: Sat, 14 Nov 1992 02:01:22 GMT

: exists there any filters to print ASCII-files on a Postscript
: Printer (HP) ? Could you please mail me your informations !

I've been using psf quite happily on my Ultrix box and recommend it.

	fsa.cpsc.ucalgary.ca:/pub/psf/

--
hirai@cc.swarthmore.edu (Eiji Hirai)    :     :    :   :  : :: ::: :::: :::::
Unix Geek for Swarthmore College        :     :    :   :  : :: ::: :::: :::::
Information Services, Swarthmore, PA, US.       Copyright 1992 by Eiji Hirai.
I don't speak for Swarthmore College.                    All Rights Reserved.
Newsgroups: comp.unix.ultrix