HDTenEightyP/NetNews huggingface dataset:
From: miguel@boytoy.csd.sgi.com (Michael/Miguel Sanchez)
Subject: Re: Return of the Poor NFS performance
Organization: Silicon Graphics, Inc.
Distribution: comp
Date: Fri, 22 Jan 1993 22:14:47 GMT

In article <JP107.93Jan22121147@grus.cus.cam.ac.uk>, jp107@cus.cam.ac.uk (Jon Peatfield) writes:
|> Ok, I've had a few nice chats with some of the readers of this group
|> and with our local SGI support line, who are currently off chasing the
|> fact that this has been reported to them before but they couldn't find
|> what had happened last time (what kind of help-desk software does the
|> support line use?)
|> 
|> Anyway it turns out that my SGI Indigos can only push files over NFS
|> at about 10 to 30 Kbytes/sec (after the patch mentioned below) while
|> all the rest of our machines (Sun/HP/Mac), can manage over
|> 110Kbytes/sec (I have a large number of figures if you want them.)  I
|> got a set of patches from SGI for general network performance (a new
|> ethernet device driver), which improved performance a good deal, but
|> still didn't put it in the acceptable range.  After hitting my head
|> for a while and replacing transceivers and moving machines etc, I
|> watched the network with etherfind (great tool -- why don't SGI
|> provide it?) and spotted that the SGIs are waiting after each NFS
|> write for an acknowledgement from the server.  Our servers don't
|> acknowledge 'til the block is on physical disk (like normal machines),
|> so there is a huge wait.  This is as if the biod daemons are not
|> working (but we have four (4) running.)  On all the other machines in
|> the dept, if I have N biods then I don't see blocking 'til N+1
|> requests are outstanding.  The delays get worse when one is over a
|> high latency netwrok while other machines just cope.  What is worse is
|> that if the Acknowledgement reply is lost (as sometimes happens on
|> ethernets (it is UDP after all)), the SGI waits for 4.5 SECONDS before
|> retrying the send.  A few of those and the time really adds up.

it almost sounds like you are hard mounting the nfs mount points...are you
doing that?




-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Miguel (Michael) J. Sanchez
miguel@csd.sgi.com			
Member Technical Staff, Silicon Graphics, Inc.
From: portuesi@tweezers.esd.sgi.com (Michael Portuesi)
Newsgroups: comp.sys.sgi.admin
Subject: Re: Of Mice and SGI
Date: 26 Jan 93 23:24:48 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA


In article <1993Jan26.184818.1413@aio.jsc.nasa.gov>, odonnell@sweetpea.jsc.nasa.gov writes:
> I've been working with SGI hardware for a number of years
> now and have come to expect high quality products. But
> I have to tell you SGI, ever since the introduction of 
> mechanical mice, I've come to expect less than high quality
> hardware. Where else are you cutting corners on quality?

This is definitely a case of "you can't please all of the
people all of the time."  It's much like choosing your
favorite text editor - some people like optical mice,
others mechanical.  Even here at SGI, there are occasional
public debates about which is better.

As for myself, I have both an Indigo (mechanical mouse)
and a PI (optical mouse) on my desk.  I don't have much
of a preference for one over the other.  Actually, I
understand that one of the reasons for switching to the
mechanical mouse is that the optical mice had a high
failure rate.  I'm not sure "cutting corners on quality"
was a prime motivation...

--
Michael Portuesi   Silicon Graphics, Inc.   portuesi@sgi.com
Xref: sparky comp.sys.sgi.admin:296 comp.sys.sgi.hardware:201
From: jeffs@soul.esd.sgi.com (Jeff Smith)
Newsgroups: comp.sys.sgi.admin,comp.sys.sgi.hardware
Subject: Re: problem upgrading from R3K to R4K Indigo
Keywords: indigo, R4000, upgrade
Date: 26 Jan 93 05:10:36 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1993Jan26.014846.1473@kronos.arc.nasa.gov> doctor@tardis.arc.nasa.gov (Terry Fong) writes:

>I have no problem booting the machine from CD (which I did to upgrade
>to 4.0.5F). Also, if I replace the old R3000 board, the machine boots
>fine as well.

You need to re-install software with the R4000 board installed.  It
should be detailed in the release notes for the upgrade.

jeffs@sgi.com
Newsgroups: comp.sys.sgi.admin
From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver)
Subject: Re: Sync'ing clocks
Organization: Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 28 Jan 1993 02:15:11 GMT

In article <vdk8hdg@zola.esd.sgi.com>, olson@anchor.esd.sgi.com (Dave Olson) writes:
> In <C1I61s.5Jz@demon.co.uk> pettsj@visigoth.demon.co.uk (James Petts) writes:
> 
> | The best way to sync clocks on a small network is to use timed(1M). The 
> | man page for this is quite lucid. You will need to make sure timed is 
> | turned on using chkconfig. The actual command which turns timed on is in 
> | /etc/init.d/network, which is executed at boot.
> 
> Or large networks.  Most of the > 2000 systems on the SGI campus
> on about 100 Class C nets use timed to keep the clocks in sync.
> Another big chunk use xntp (including most of our WAN, but that
> is as much because of the group responsible for WAN sites as anything
> else, timed does work fine on WANs).


I think they use NTP to fix the clock of a single machine on each
network (i.e. "broadcast domain"), and also turn on timed with
"-F localhost" in /etc/config/timed.options.

Care must be exercised with "-F localhost" to ensure that at most one
machine on each network is so officious.  Two or more will fight and
keep the time from being syncrhonized, not to mention corrected.

You can use timeslave in the same was as xntpd to make a local time
master.  Timeslave is said to use far fewer CPU cycles, and I think it
takes less configuring than xnptd.  Timeslave does not require that the
remote time machine be running anything but common Internet Protocol
time services, while xntpd requires the remote machine to support NTP.
On the other hand, timeslave does not use an officially sanctioned or
publically reviewed synchroniziation protocol.


For most purposes, the out-of-the-box configuration of timed works for
most situations.  That default configuration is to have all machines
run `timed`, with no special forcing of the moderator.  (The `timed`
"master" is really more of a moderator that averages all of the clocks
on the network.)  To synchronize such a default network of IRIS's to
the correct time, simply use the `date` command on one of them daily or
twice daily for a month or so to correct the time.  This will cause
each machine to compute a good "timetrim value" or figure for its long
term drift in /usr/tmp/.timetrim.  A gaggle of machines all with good
timetrim values, at least one of which is always powered on, should
keep time almost as well as a $3 electronic clock.


Vernon Schryver,  vjs@sgi.com
From: phaedrus@alioth.cc.nps.navy.mil (Matthew Koebbe)
Newsgroups: comp.sys.sgi.admin
Subject: Sync'ing clocks
Date: 26 Jan 93 21:03:51 GMT
Distribution: usa
Organization: Naval Postgraduate School


Short and to the point:

  The clocks on our SGI workstations (3 Personals and a 380 Power Station)
are continually drifting.  We'd appreciate any input on how to automatically 
sync these things, say, once a day?  

  Thanks.

				--matthew
-- 

---------------------------------------------------------------------------
Matthew Koebbe              (408)656-2571 | I don't find this stuff amusing
Scientific Visualization Group, NPS       |  anymore.
From: avi@golem.apple.com (Avi Weiss)
Newsgroups: comp.sys.sgi.admin
Subject: looking for CC files
Date: 22 Jan 93 19:50:47 GMT
Organization: Apple Computer, Inc.

Hi all -

I'm trying to build gcc and I'm using CC to do it.
During compilation, cc tries to include the file:

/usr/include/cmplrs/stsupport

from inside the file /usr/include/syms.h (on line 113)

unfortunatly, such a subdirectory does not exist. I haven't been
able to find stsupport with find. 

As I'm sure many people have built gcc, someone must have run across
this problem. 

any help would be greatly appreciated.

thanks

- Avi 

--------------------
Avi Weiss 

email: (avi@apple.com)
phone: (408) 974-0582

Of course I don't speak for Apple...they don't pay me enough to do so. 
Newsgroups: comp.sys.sgi.admin
From: shenkin@still3.chem.columbia.edu (Peter Shenkin)
Subject: Re: mouse cleaning
Organization: Dept. of Chem, Columbia U, New York
Date: Thu, 21 Jan 1993 16:06:19 GMT
X-Posted-From: still3.chem.columbia.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

In article <1993Jan20.221257.981@bitrot.in-berlin.de> thomas@bitrot.in-berlin.de (Thomas Driemeyer) writes:
>You have a rough section on the rollers? I don't. After almost a year,
>the mouse cannot be moved slowly any more, the ball always slips.
>Cleaning the ball with alcohol didn't help, and neither did cleaning
>the rollers. I had to slip some rubber tubing over the rollers to get
>the mouse to work again.

I've not seen the mechanical mice, but if the ball is rubber, try cleaning
it with carbon tetrachloride or dry-cleaning fluid.  This should remove
a small amount of the rubber surface and roughen it up a bit.

	-P.
-- 
************************f*u*cn*rd*ths*u*cn*gt*a*gd*jb************************
Peter S. Shenkin, Box 768 Havemeyer Hall, Dept. of Chemistry, Columbia Univ.,
New York, NY  10027;  shenkin@still3.chem.columbia.edu;  (212) 854-5143
******* ...ghostlier demarcations, keener sounds.  (Wallace Stevens) ********
Newsgroups: comp.sys.sgi.admin
From: mancus@sweetpea.jsc.nasa.gov (Keith Mancus 283-4283)
Subject: Mechanical vs Optical mice (was Re: mouse cleaning)
Organization: MDSSC
Distribution: na
Date: Fri, 22 Jan 1993 18:51:56 GMT

In article <35174@adm.brl.mil>, blbates@aero36.larc.nasa.gov (Brent L. Bates ViGYAN AAD/TAB) writes:
|> 
|>      You're being sarcastic, right?!
|>      I want my optical mouse back!!!!!!!!!!!!!!!!!!!!!!!!

|>      SGI read my electrons!  Give us back our optical mice!

  Most of our users feel the same way.  Whenever we are forced to
replace an optical mouse with a mechanical mouse, loud groans are heard.
I, too, prefer the optical.

-- 
| Keith Mancus    <mancus@cheers.jsc.nasa.gov>                           |
|                 N5WVR                                                  |
| "Money is never *mere*.  It separates the feasible                     |
|    from the infeasible."                                               |
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi.admin
Subject: Re: OS version confusion (again!)
Date: 22 Jan 93 08:44:03 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1993Jan21.223616.11831@cs.yale.edu> nathan@laplace.biology.yale.edu (Nathan F. Janette) writes:
| I have a Crimson that is running:
| 
| 	Irix 4.0.5 A
| 	Compilers 3.10
| 
| We are having a problem with segmentation errors in a fortran program,
| which might be a bug mentioned as fixed in the release notes for Irix
| 4.0.5C (now Irix 4.0.5F?).  I want to upgrade the Crimson to:
| 
| 	Irix 4.0.5 C or F

C; F isn't supported on Crimson, unless you have RE graphics.
As I recall, C isn't a real release, just some patches, but I
could be wrong.

| 	Compilers 3.10

Nothing to change here; you already have it.

| Here's the kicker: the compilers disk also installs some form of eoe1. 

/lib/cpp and stuff under /usr/sysgen/root.  Load the compilers eoe
stuff again (with 'set neweroverride') if you really want the newer
cpp; If you are doing ANSI C, you don't use that anyway, so it probably
doesn't matter.

--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
Newsgroups: comp.sys.sgi.admin
From: jp107@cus.cam.ac.uk (Jon Peatfield)
Subject: Return of the Poor NFS performance
Organization: U of Cambridge, England
Distribution: comp
Date: Fri, 22 Jan 1993 12:11:53 GMT

Ok, I've had a few nice chats with some of the readers of this group
and with our local SGI support line, who are currently off chasing the
fact that this has been reported to them before but they couldn't find
what had happened last time (what kind of help-desk software does the
support line use?)

Anyway it turns out that my SGI Indigos can only push files over NFS
at about 10 to 30 Kbytes/sec (after the patch mentioned below) while
all the rest of our machines (Sun/HP/Mac), can manage over
110Kbytes/sec (I have a large number of figures if you want them.)  I
got a set of patches from SGI for general network performance (a new
ethernet device driver), which improved performance a good deal, but
still didn't put it in the acceptable range.  After hitting my head
for a while and replacing transceivers and moving machines etc, I
watched the network with etherfind (great tool -- why don't SGI
provide it?) and spotted that the SGIs are waiting after each NFS
write for an acknowledgement from the server.  Our servers don't
acknowledge 'til the block is on physical disk (like normal machines),
so there is a huge wait.  This is as if the biod daemons are not
working (but we have four (4) running.)  On all the other machines in
the dept, if I have N biods then I don't see blocking 'til N+1
requests are outstanding.  The delays get worse when one is over a
high latency netwrok while other machines just cope.  What is worse is
that if the Acknowledgement reply is lost (as sometimes happens on
ethernets (it is UDP after all)), the SGI waits for 4.5 SECONDS before
retrying the send.  A few of those and the time really adds up.

I don't want to imply that SGI arn't dealing with this, but I was
hoping that someone else has seen this and knows the cure -- have I
messed something up with the biods or is this normal SGI behavour?

-- Jon Peatfield  (Unix network admin)

Jon Peatfield, Computer Officer, the DAMTP, University of Cambridge
Telephone: (+44 223) 3-37852     Mail: J.S.Peatfield@amtp.cam.ac.uk

To be consistent with DNS domain ordering, shouldn't news groups have
names like "admin.sun.sys.comp" not "comp.sys.sun.admin" ?  EMWTK
--
Jon Peatfield, Computer Officer, the DAMTP, University of Cambridge
Telephone: (+44 223) 3-37852     Mail: J.S.Peatfield@amtp.cam.ac.uk

To be consistent with DNS domain ordering, shouldn't news groups have
names like "admin.sun.sys.comp" not "comp.sys.sun.admin" ?  EMWTK
From: blbates@aero36.larc.nasa.gov (Brent L. Bates ViGYAN AAD/TAB)
Newsgroups: comp.sys.sgi.admin
Subject: Re: mouse cleaning
Date: 22 Jan 93 13:07:15 GMT


     You're being sarcastic, right?!
     I want my optical mouse back!!!!!!!!!!!!!!!!!!!!!!!!
     Actually, our three older systems still have the superior optical mice,
so I'm only annoyed when I have to use our new Indigo that has the crummy
machanical mouse.  I have yet to hear any one give me an inteligent reason
why they prefer machanical mice.  You still need a pad for them.  The balls
tend to `jam' and jurk.  They are heavy.  And most of all they are machanical,
so they have parts that easily ware out, get dirty, etc..
     SGI read my electrons!  Give us back our optical mice!

  Brent L. Bates				Phone:(804) 864-2854
  M.S. 361			  		  FAX:(804) 864-8469
  NASA Langley Research Center
  Hampton, Virginia  23681-0001
  E-mail: blbates@aero36.larc.nasa.gov or blbates@aero00.larc.nasa.gov

Newsgroups: comp.sys.sgi.admin,comp.unix.aix
From: rdew@alw.nih.gov (Bob Dew)
Subject: Re: Is NFS a dead-end on PC's?
Organization: National Inst. of Health, DCRT, CSL
Date: Thu, 21 Jan 1993 23:48:07 GMT

A reason why PCNFS may not be widely popular in networks shared by PC
and UNIX hosts may simply be that PCs presently lack commercially available 
application software that can take advantage of merging PC and UNIX 
filesystems.

Where NOS systems, like the ones you mention, can provide immediate 
"plug-and-play" solutions to file management and mail exchange issues, 
PCNFS merely represents a tool whereby a UNIX file system may be accessed 
from DOS.  PCNFS by itself does not address real-life issues seemingly as 
simple as, "how can person 'a' send a message to person 'b'?", or "how can 
you make a shared software package available to some users, but not to 
others?", and so on. To compound the problem, most UNIX-based systems (with
the notable exception of AFS), and certainly most NFS-based applications, 
aren't designed to accommodate several thousands of simultaneous users, such 
as may be the case in today's large-sized LANS.  

I think PCNFS could potentially be very valuable in bridging the gap 
between PCs and UNIX machines sharing the same network, but the applications 
software has yet to be written.
 
-Bob

Bob Dew
National Institutes of Health
Newsgroups: comp.sys.sgi.admin
From: mbersohn@alchemy.chem.utoronto.ca (M. Bersohn)
Subject: SGI FILE FORMAT
Organization: University of Toronto Chemistry Department
Date: Fri, 22 Jan 1993 14:57:04 GMT

Hello SGI users:
    Does anyone know where I can find a detailed description of the
file format of the SGI image files? This appears to be a closely
guarded secret. Plenty of books will tell you about TIFF, PCX
etc. but the SGI hot line will not divulge the format of
something.rgb. I have full support on my machine but all the
support line could do was point me to some source code examples
in 4Dgifts. With a few weeks time, many of the routines call
each other, I might finally deduce what is the meaning of byte
0, what is stored at the four byte field beginning at byte 12
etc. etc. It sure would be nice to have an explicit description
so I could begin my real work today!
    Thanks in advance to anybody who knows and will divulge this
deep dark secret.
    Kindly email to me at
mbersohn@alchemy.chem.utoronto.ca.
    Thanks.
Malcolm Bersohn
Newsgroups: comp.sys.sgi.admin,comp.sys.sgi.hardware
From: doctor@kronos.arc.nasa.gov (Terry Fong)
Subject: Re: problem upgrading from R3K to R4K Indigo
Summary: it still ain't going...
Keywords: indigo, R4000, upgrade
Organization: NASA/ARC Information Sciences Division
Date: Tue, 26 Jan 1993 07:07:57 GMT

In article <vbhp6uo@zola.esd.sgi.com> jeffs@soul.esd.sgi.com (Jeff Smith) writes:
>In <1993Jan26.014846.1473@kronos.arc.nasa.gov> doctor@tardis.arc.nasa.gov (Terry Fong) writes:
>
>>I have no problem booting the machine from CD (which I did to upgrade
>>to 4.0.5F). Also, if I replace the old R3000 board, the machine boots
>>fine as well.
>
>You need to re-install software with the R4000 board installed.  It
>should be detailed in the release notes for the upgrade.

Funny thing. That's exactly what I did... but it still didn't boot
(same error). I booted the Indigo using a 4.0.5F (Indigo/Reality
Engine only) CD, upgraded from that disc, then used the 4.0.5F
maintenance disc. No luck...

Further info on the system: 32 MB RAM, 432 MB disk, Elan graphics. The
system had been upgraded to 4.0.5F with the Elan upgrade (a few weeks
back). After installing the R4K board and trying to upgrade from CD,
inst did not seem to try and add very much at all.


-Terry
-- 
_______________________________________________________________________________
A straight line may be the shortest     Terry Fong <terry@ptolemy.arc.nasa.gov>
distance between 2 points, but it is     NASA-AMES M/S 269-3, Moffett Field, CA
by no means the most interesting-Dr. Who    (415) 604-6063 office, 604-6081 lab
Xref: sparky comp.sys.sgi.admin:299 comp.sys.sgi.hardware:204
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi.admin,comp.sys.sgi.hardware
Subject: Re: problem upgrading from R3K to R4K Indigo
Keywords: indigo, R4000, upgrade
Date: 26 Jan 93 06:32:43 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1993Jan26.014846.1473@kronos.arc.nasa.gov> doctor@tardis.arc.nasa.gov (Terry Fong) writes:
| I am trying to upgrade an Indigo Elan from R3000 to R4000 and have run
| into a bit of a problem: when I try to boot the machine (with R4000)
| installed, I get the following error message:
| 
|   Cannot load scsi(0)disk(1)rdisk(0)partition(8)/sash
|   Unable to load bootfile: not enough space

Sounds as though you somehow used fx to decrease the size of the
volume header below the size used by sash and other program in
the volhdr.

| Also, if I try running diagnostics from the PROM monitor, I get:
| 
|   Cannot load scsi(0)disk(1)rdisk(0)partition(8)ide
|   Error 16 while loading scsi(0)disk(1)rdisk(0)partition(8)ide
| 

16 is the arcs ENOMEM.  Sounds like the ide in the volume header
may have been trashed.

| I have no problem booting the machine from CD (which I did to upgrade
| to 4.0.5F). Also, if I replace the old R3000 board, the machine boots
| fine as well.

I assume you mean you can boot from CD; it certainly shouldn't boot
from disk if the upgrade was completed OK.

I've not heard of people having these problems before; perhaps you
can describe what, if anything,  you did after installing the new
software that might have been 'unusual'.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: duong@chestnut.chem.upenn.edu (Duc Duong)
Newsgroups: comp.sys.sgi.admin
Subject: Weird, Strange Cron output error..HELP..
Date: 28 Jan 93 13:15:28 GMT
Organization: NMR Biochemistry Graduate Research Lab

hi..

During the past three months, every night I received the following
cron output error message from one of my PI35 machine. I tried to fix
the disk, reinstall the intire operating system, upgrade to 4.05..etc
and none worked. All of the files in  /pkg/..etc..exist..but the
error says no such files. The message is different every night for the
/tmp/croutXX files..

(first day)
find: stat() failed: /tmp/croutRFAa00218: No such file or directory
find: stat() failed: /tmp/croutSFAa00218: No such file or directory
find: stat() failed: /pkg/users/cw/trans: No such file or directory
find: stat() failed: /pkg/users/cw/chinese: No such file or directory
find: stat() failed: /pkg/users/cw/lgcorr.mat: No such file or directory
find: stat() failed: /pkg/users/cw/xfonts: No such file or directory
find: stat() failed: /pkg/users/cw/install: No such file or directory
find: stat() failed: /pkg/users/cw/News: No such file or directory
find: stat() failed: /pkg/users/bb: No such file or directory
find: stat() failed: /pkg/users/rm: No such file or directory
find: stat() failed: /pkg/users/duc: No such file or directory
find: stat() failed: /pkg/users/jjg: No such file or directory
find: stat() failed: /pkg/users/bsa: No such file or directory
find: stat() failed: /pkg/users/nmr: No such file or directory
find: stat() failed: /pkg/users/pas: No such file or directory
find: stat() failed: /pkg/info: No such file or directory


(second day)
find: stat() failed: /tmp/croutINAa00218: No such file or directory
find: stat() failed: /pkg/users/cw/trans: No such file or directory
find: stat() failed: /pkg/users/cw/chinese: No such file or directory
find: stat() failed: /pkg/users/cw/lgcorr.mat: No such file or directory
find: stat() failed: /pkg/users/cw/xfonts: No such file or directory
find: stat() failed: /pkg/users/cw/install: No such file or directory
find: stat() failed: /pkg/users/cw/News: No such file or directory
find: stat() failed: /pkg/users/bb: No such file or directory
find: stat() failed: /pkg/users/rm: No such file or directory
find: stat() failed: /pkg/users/duc: No such file or directory
find: stat() failed: /pkg/users/jjg: No such file or directory
find: stat() failed: /pkg/users/bsa: No such file or directory
find: stat() failed: /pkg/users/nmr: No such file or directory
find: stat() failed: /pkg/users/pas: No such file or directory
find: stat() failed: /pkg/info: No such file or directory

I think that some how, the system can't find the /tmp/crout*
files..so It can't find the rest... Are the any way to fix this?
E-mail please. Thank you.

Duc




Newsgroups: comp.sys.sgi,comp.sys.sgi.misc