HDTenEightyP/NetNews huggingface dataset:
From: mds@sgi.com (Mark Stadler)
Newsgroups: comp.sys.sgi
Subject: Re: swapbuffers() and finish()
Date: 10 Oct 92 23:13:18 GMT
Organization: Silicon Graphics, Inc.
NNTP-Posting-Host: mds.asd.sgi.com

In article <32979@adm.brl.mil> roger@rod.swmed.utexas.edu (Roger S. Noss) writes:
>
>  I want to reliably swap buffers and record the time of the swap.
>  The only command to do this that I have found is finish().  My
>  window is small (512 x 512 or so) and the pattern is simple.
>  Occasionally finish() blocks for an extra frame - maybe 10% of
>  the swaps.  Short of putting a photocell to the monitor and 
>  omitting finish(), how can I improve the timing?  Is this a unix
>  problem?  The problem is especially vexing for vision expts in
>  which smooth motion is desired - if a refresh is missed, the
>  line is redisplayed in its old position, then jumps twice the
>  distance to catch up in the next frame.
>  
>  Any ideas?
>  
>  - Roger

you're right, swapbuffers() and gsync(), are implemented with a
late-binding behavior to give GL programs a chance to do computation
while waiting for vertical retrace.

that is, when you call swapbuffers(), the kernel drops the appropriate
hardware dependent tokens into the pipe, UNMAPS the pipe from user space,
and returns without waiting for completion.  the next time the GL program
attempts to touch the graphics pipe, it will page fault and sleep until
the vertical retrace has occured.

to get an accurate measure of frame time including waiting for swapbuffers(),
you can drop some simple command (like cpack(0x0)) right after swapbuffers()
and before your timer call.


starttimer();
render frame();
swapbuffers();
cpack(0x0);
stoptimer();

your finish() idea was close, but a finish operation is relatively heavy-weight
since it passes data all the way thru the pipe after the swapbuffers() is done,
so it will bias your results much worse than cpack().

--
-- mds	[aka Mark D Stadler  mds@sgi.com  ...!uunet!sgi!mds  (415)335-1327]
Newsgroups: comp.sys.sgi
From: jdyvig@photon.com (Jim Dyvig)
Subject: TAE and GL
Organization: Photon Research Associates, Inc.
X-Newsreader: TIN [version 1.1 PL6]
Date: Sat, 10 Oct 1992 03:12:08 GMT

I'm attempting to use TAE and GL.  More specifically, I would like to use some
X/Motif GUI builder (we have TAE) with Inventor (or GL).  After some mucking
around, I found that Inventor conflicted somehow with TAE.  I imagine the
event handlers and duplicate routine names (such as 'clear') are the
culprits.  I have also tried using GL/X with more luck.  As long as I
don't use 'clear' in my GL routines, I am fine.

Has anyone else had more luck than I?  If so, I would appreciate any hints
that people can offer.

Thanks.

Jim Dyvig
Photon Research Associates
jdyvig@photon.com or jdyvig@photon@ucsd.edu
Newsgroups: comp.sys.sgi
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: Indigo-Indigo Ethernet problem
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 15 Oct 92 00:36:16 GMT

In <1992Oct14.225240.11509@imax.imax.com> dave@imax.imax.com (Dave Martindale) writes:

|  /usr/adm/SYSLOG reports "IRIX Release 4.0.5F IP12 Version 08280217 System V"
|  on the R3000 machine.  It's only 6 months old (April 92) so it's
|  not early hardware.

Hmm.  Sounds pretty definite!

|  >You could watch it with netsnoop if you have that software.  There
|  >are also some similar packages for Sun's.  That may tell you where
|  >the delays are.  The indigos (both) can send ack's back closer to
|  >the minimum times allowed by the spec than a number of other chips,
|  >and this sometimes causes higher collision rates, but it shouldn't
|  >cause the kind of performance problem that you are reporting.
|  
|  Unfortunately, I don't have any snooping software at the moment.
|  The pauses in Indigo-Indigo transmission do seem to be correlated
|  with the CRC error printfs when "ifconfig debug" is done.

Be aware that *everything* grinds to a halt during any kind of
kernel printf.  I should have mentioned that, but I tend to
assume everybody is aware of it.  Any time you get any significant
number of kernel printfs, you will drop characters on the serial
ports, and probably drop ethernet packets.  That *will* cause
delays!

|  We do indeed get lots of collisions, but as you note a collision should
|  *not* cause a lost packet if everything is working correctly.

Yes, but see above.

|  Let me clarify.  The R4000 machine does *not* count SQE as a collision.
|  The R3000 machine *does* count it, even though it is definitely
|  running 4.0.5F.  I just checked again - with SQE off on the transceiver,
|  there are only occasional collisions.  With SQE on, the collision count
|  (as reported by netstat -i) is always at least equal to the outgoing
|  packet count, and sometimes a few more.

Sounds like we may have broken something then.  We will have to look
into this some more.
--
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
From: sridhar@enuxhb.eas.asu.edu (Sridhar Venkataraman)
Subject: Re: Why is the PATH hardcoded for rsh?
Organization: Arizona State University, Tempe AZ
Date: Wed, 7 Oct 1992 16:56:56 GMT

[My apologies if you saw the same followup before. My news server
seems to be having some problem.]
 
olson@anchor.esd.sgi.com (Dave Olson) writes:

)Remember that a non-interactive rsh doesn't result in ~/.login
)being run (for csh users), so perhaps you should set it in .cshrc
)for non-interactive shells.

Yes, I do set my path in ~/.cshrc. Here is what it says:

I have the statements surrounded by if and endif for different
machines but this is what essentially happens for an SGI machine
(4D/35 Irix 4.0.5). I have the system-set path stored in OLDPATH and
when I source .cshrc everytime my PATH is recomputed. OLDPATH is a
env. var for the sake of rn  etc. which pass only env vars to its spawned
shells.

-----------
if ( $?OLDPATH ) then
#For debugging ...
	echo $OLDPATH
else
	setenv OLDPATH `echo $PATH | sed -e 's/\.//g'`
endif

set mypath=	(~sridhar/bin ~sridhar/scripts /etc /usr/lib )

set path=		( $mypath )
setenv PATH	$PATH\:$OLDPATH
unset mypath 
-----------

This way any user of the machine hardly needs to update his PATH when
there are any new entries added. Well, I think I will have to use
symbolic links from my own directories.

Thanks for the reply. 

Sridhar.
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.sys.sgi
Subject: Re: Indigo-Indigo Ethernet problem
Date: 14 Oct 92 06:08:52 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

| I have two Indigos, one R3000 and one R4000.  They are about 20 wire
| feet apart on an Ethernet.  When I try to pass files between them
| using rcp, the transfer goes well for a while (a fraction of a second
| to a few seconds), then it pauses for a second or so, then it resumes
| only to pause again shortly after.  This certainly kills throughput.

You shouldn't see this if the r3k indigo is running 4.0.5 (any flavor),
as it contains some workarounds for some hardware problems that are
somewhat similar to this.  The r4k indigo has a newer version of the
ethernet controller chip that should pretty much eliminate this kind
of problem.

| I've turned on debugging (ifconfig ec0 debug) on both ends.  When the
| R4000 is sending to the R3000, the R4000 end is happy but the R3000
| end reports many CRC errors and the occasional packet framing error.
| When the transfer is in the other direction, the R4000 sees the
| occasional error of both types, while the R3000 sees many packet
| framing errors and the occasional CRC error.

Sounds like you don't have 4.0.5 on the r3k then; I'd install it
and see if that helps.

| If I put the network back together and try rcping stuff to and from
| a Sun 4/260, I find that either Indigo can send to the Sun without
| many problems, and the Sun can send to the R3000 ok, but transfers
| from the Sun to the R4000 are terrible.  The R4000 doesn't report
| many errors in this case, but there are many pauses.  I don't know
| what the Sun sees; it doesn't have ifconfig debug.

You could watch it with netsnoop if you have that software.  There
are also some similar packages for Sun's.  That may tell you where
the delays are.  The indigos (both) can send ack's back closer to
the minimum times allowed by the spec than a number of other chips,
and this sometimes causes higher collision rates, but it shouldn't
cause the kind of performance problem that you are reporting.

| The transceivers used were Lantronix LTX-2 and Cabletron ST-500.
| Which transceiver was on which machine didn't seem to make any difference.
| One curious thing I did notice: the R3000 Indigo counts SQE test (heartbeat)
| as a collision, while the R4000 doesn't.  Both Indigos are running
| 4.0.5F.

4.0.5 based indigos should *not* count SQE as a collision.  Are you
*sure* that it is counting SQE as collision, and that both are running
F (all r4k indigo's should be, although a few early ones went out
with E)?
--
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: beyer@bflsgu.fl.bs.dlr.de (R. Beyer)
Newsgroups: comp.sys.sgi
Subject: Brad Zoltick
Date: 14 Oct 92 09:01:02 GMT


Mail to you regarding /dev/plp gets bounced. What is your Internet
address ?

Sorry to all others.

----------------------------------------------------------------------
Ralf Beyer - German Aerospace Research Establishment, Institute for 
Flight Guidance, Flughafen, D-3300 Braunschweig, Fed. Rep. of Germany
	  Phone: 0049-531-395-2530  Fax: 0049-531-395-2550
Internet: beyer@bflsgu.fl.bs.dlr.de (EARN/BITNET: fl17@dlrvmbs.bitnet) 
----------------------------------------------------------------------

Newsgroups: comp.sys.sgi
From: story@sgi.com (David (Duis) Story)
Subject: Re: Where are preferences stored in Showcase?
Organization: Silicon Graphics, Inc.
Date: Wed, 7 Oct 92 20:29:04 GMT

In article <1992Oct6.204427.19223@tin.monsanto.com> tndoma@ddpi6 (Thompson Doman) writes:
>I've checked the written and internal documentation for Showcase
>and I just can't seem to find where the preferences (e.g., for
>color) are stored.  A coworker of mine has made some nice changes
>to the color palette in his version of showcase and I'd like to
>use that palette, but I have no idea how to get the color
>preferences from him.  Anybody have any ideas?

Sure, take a look at (depending on which version of showcase you have)
~/.mem_pro or ~/.show_pro.

Cheers,

David Story                        	        Silicon Graphics, Inc.
story@bent.wpd.sgi.com				Mountain View, California

I've changed my name, so duis@sgi.com may bounce, please use story@sgi.com.
Newsgroups: comp.sys.sgi
From: olson@anchor.esd.sgi.com (Dave Olson)
Subject: Re: something wrong with tar or me?
Keywords: tar, uncompress
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Thu, 15 Oct 92 00:24:00 GMT

In <9871@fs3.cam.nist.gov> gpfrn@cam.nist.gov (Glenn_P._Forney_x2313) writes:

| i ftp'd (with bin option) the file dvips5493lib.tar.Z
| ( a dvi to postscript converter used with tex) from labrea.stanford.edu
| ( in /pub) to a sgi 4d35 running system 4.0.5 .
| after uncompressing, i got the following output upon using
| tar xvf dvips5493lib.tar
| x PSvfs/ptmrrn.vf, 1844 bytes, 4 blocks
| x PSvfs/pzcmi.vf, 1824 bytes, 4 blocks
| x afm-extra/Makefile, 8337 bytes, 17 blocks
| x afm-extra/ptmr.ed, 1907 bytes, 4 blocks
| x afm-extra/ptmro.ed, 2116 bytes, 5 blockstar: tape blocksize error
| 
| apparently the last file, ptmro.ed, was not untarred properly.
| (here is a ls -l listing of the afm* files :
| 
| -rw-r--r--   1 gpfrn    user        8337 Aug 28 22:42 Makefile
| -rw-r--r--   1 gpfrn    user        1907 Aug 28 22:42 ptmr.ed
| -rw-r--r--   1 gpfrn    user        1024 Oct 14 12:44 ptmro.ed
| 
| )
| note the difference between 2116 which tar reported above and the actual
| value of 1024 reported by ls.

My guess is that you ran out of disk space somewhere along the line,
and the archive was truncated.
--
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
From: steve@europa.esd.sgi.com (Motorin' Flarey Henderson)
Subject: Re: What's the diff: Indigo vs. Crimson?
Organization:  Silicon Graphics, Inc.  Mountain View, CA
Date: Fri, 16 Oct 92 17:03:38 GMT

In <1992Oct16.144954.11214@odin.corp.sgi.com> mas@everest.esd.sgi.com (Michael Schulman) writes:

>In article <1992Oct16.030547.784@news.acns.nwu.edu>, gof@casbah.acns.nwu.edu (Gerald Fountain) writes:
>|> 
>|> I have been attempting to make some machine comparisons (mainly benchmark
>|> data) and someone raised a question.  What is the difference between a Crimson
>|> and an Indigo (both R4K)?  Someone stated that the Crimson was basically the
>|> same machine in a bigger box and more expansion abilities (more slots and
>|> bays).  Can someone straighten me out on the issue?
>|> 

>Basically the Crimson and Indigo R4K have the same CPU.  The advantage to
>the Crimson is that it is expandable , VME slots ( as you noted ) , and can
>have both the VGXT and RE graphics options, which the Indigo cannot.  Currently
>with existing memory technology, the Crimson can go up to 256 Mbytes, while
>the Indigo only 96, although the Indigo R4k will handle 384 Mbytes in the
>future.

As for performance, the Crimson's main memory is 4 way interleaved 
(256 bits wide!), while the Indigo R4K is 2 way interleaved.  Therefore,
the Crimson can fill the primary and secondary caches faster.  Since both
Crimson and Indigo R4K have the same size and speed secondary cache,  the
faster memory bus is a second order effect.  It depends on what you're running.
Also, an Indigo will run the Elan graphics board faster than a Crimson will
run it, since the GIO bus isn't native to the Crimson.  Of course, the Crimson
can also run VGX and RE, which the Indigo never will...

Oh, and the Indigo R4K is much less expensive and cuter, too!  %^>

--
steve valin		steve@sgi.com
		"Vote for Ross Perot - It'd be funny" 	- Letterman
From: calvin@dinkum.mti.sgi.com (Calvin Vu)
Newsgroups: comp.sys.sgi
Subject: Re: Compiler or linker bug?
Date: 14 Oct 92 23:04:44 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <Bw1JD8.54w@helios.physics.utoronto.ca> grindley@helios.physics.utoronto.ca (Robin Grindley) writes:

| This bug seems to be pretty version independent - it occurs on 3.3.3, 4.0.4,
| and 4.0.5 (with 3.10 compilers). Someone was trying to add one more common
| block to a block data routine in f77. Compiled fine - NOTE that *all* of our 
| code is compiled with -G 0. So when linking we get:
| 
| genbd.o: definition of external data gnpack_
	In here, it is defined as "data", not "small data", so I guess
    it is compiled with -G 0.

| /d/cdf1/cdfman/isajet/production/library/isajet.olb(conv.o): definition of small
|  common gnpack_ size 4
	From this, it sounds like the file conv.o in
    /d/cdf1/cdfman/isajet/production/library/isajet.olb has not
    been compiled with the -G 0 flag.  You can try to recompile with
    with -G 0 and run 'stdump' on it to make sure that it is no
    longer a "small common".  If it is then it's either a bug or
    I will have to read the manual again :-)))>

- calvin
--
Calvin H. Vu	
calvin@sgi.com   
Newsgroups: comp.sys.sgi
From: mash@mash.wpd.sgi.com (John R. Mashey)
Subject: Re: file size limit (2^31?)
Organization: Silicon Graphics, Inc.
Date: Fri, 9 Oct 1992 21:53:36 GMT

In article <3031@contex.contex.com>, james@sam.contex.com (James McQueston) writes:

|> Thomas is correct.  SGI, please heed his point that "long long" is no help.
|> 
|> Those that have suffered through with SGI's early machines and compilers
|> will remember the C doubles that were IEEE single precision (technically
|> legal at the time), but the real horror was that double precision was
|> available but called "long double."
|> 
|> _Please_ (he begs while on his knees in a supplicating position) don't
|> introduce "long long" except as a 128 bit quantity.

For better or worse, the industry has added, or is adding,
long long as a 64-bit data type, evne in 32-bit environments, with
function calls to do multiply & divide, regardless of what anyone
does in 64-bit environments.

The problem is: CONVEX did it, GNU did it, several others have done it,
and everybody else is, despite the less than lovely syntax...

-john mashey    DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP:    mash@sgi.com 
DDD:    415-390-3090
USPS:   Silicon Graphics 7U-005, 2011 N. Shoreline Blvd, Mountain View, CA 94043
Newsgroups: comp.sys.sgi
From: kdeacon@nmsu.edu (DEACON)
Subject: Setting up SLIP
Organization: NMSU Computer Science
Distribution: comp.sys.sgi
Date: Fri, 16 Oct 1992 21:29:03 GMT

Does anyone have a good explanation on how to set up a slip connection
for a X terminal over a directly connected serial line?  Any help
would be appreciated.  Thanks, Keith.
From: jordan@IMSI.COM (Jordan Hayes)
Newsgroups: comp.sys.sgi
Subject: Hacking Back To The Stone Ages
Date: 8 Oct 92 20:56:37 GMT
Organization: Investment Management Services Inc., NYC

Hey, gotta new Indigo.  Great looking graphics.

But what about the development environment?

(accom): foobar.c, line 5098: accom: Internal:   Switch table overflow.
   Cannot continue compilation.  The current size was specified as or
   defaulted to -Wf,-Ng500 giving a table size of 500.  Recompile giving
   a command line option to increase the table size.
   Example option giving a larger table: -Wf,-XNg1000

Hello?  Earth to SGI?

Didn't these so-called dynamically sized structures go away when we
discovered realloc() ...?

/jordan
From: tima@sequent.com (Timothy Alan Anderson)
Newsgroups: comp.sys.sgi
Subject: Hook SGI CD-ROM drive to Adaptec 1542/B and whimpy DOS?
Date: 13 Oct 92 15:40:54 GMT
Article-I.D.: sequent.1992Oct13.154054.2061
Organization: Sequent Computer Systems Inc.

I know this one is bordering on a FAQ, but I have to ask again just in
case any new information has developed...

I have the SGI CD-ROM hooked up to an Adaptec 1542/B. It can read the
device type string OK, but none of the CD-ROM drivers will work at all. This
is not too surprising, given that the SGI CD-ROM has that fantastic
'proprietary' EPROM stuck in it. Is there any way to get this drive to 
respond like a CD-ROM drive? Toshiba sez "Send it to us and we will rip
out the EPROM and give you a new one." I seemed to remember that there was
some way that this thing could run under DOS given the correct SCSI
incantations... I geuss a switch on the back that read 'SGI - the rest of
the industrialized world' would have been too much to ask ;-)

tima@sequent.com
From: scotth@hoshi.corp.sgi.com (Scott Henry)
Newsgroups: comp.sys.sgi
Subject: Re: Problem with resolver on R4000 Indigo on 4.0.5F
Date: 15 Oct 92 14:39:51 GMT
Organization: Silicon Graphics Inc, Mountain View, CA


>>>>> In article <1992Oct15.131437.28859@vela.acs.oakland.edu>, bbesler@ouchem.chem.oakland.edu (Brent H. Besler) writes:

bbesler> I have an Iris R4000 Indigo/Elan running Irix 4.0.5F.  The is
bbesler> apparently a problem with the resolver.  If I setup
bbesler> resolv.conf, so that name resolution is enabled, mail and
bbesler> telnet, ftp, etc. all work fine, but the resolver seems to
bbesler> ignore the entries in /etc/hosts.  When I rename resolv.conf
bbesler> to another filename so that the resolver only checks the
bbesler> hosts file, the entries are read correctly.  I have the
bbesler> "hostrorder local bind" line in the resolv.conf file.  Is
bbesler> this a bug in Irix 4.0.5?  How does one allow namerserver use
bbesler> and local hosts file use on this system.  Our two 4D/220's on
bbesler> 4.04 work fine and don't have this "either or" problem

If you misspelled it as "hostrorder local bind" then you need to fix
it to read "hostresorder local bind" ("dns" is recognized as an alias
for "bind"). To the best of my knowledge, "hostrorder" is not an alias
fo r"hostresorder". You definitely need this set or you get the
"chicken & egg" problem with SLIP or PPP connections...

=-=-=
--
 Scott Henry <scotth@sgi.com> / Traveller on Dragon Wings
 Networking Services,        / Help! My disclaimer is missing!
 Silicon Graphics, Inc      / GIGO *really* means: Garbage in, Gospel Out
From: bob@caw2.4950tw.wpafb.af.mil (Bob Plested)
Newsgroups: comp.sys.sgi
Subject: Too many tapes!
Date: 8 Oct 92 18:00:29 GMT

Howdy netlanders,
   Yesterday I upgraded this 4D/320VGX from Irix 4.0.4 to 4.0.5A. Today
I got my SGI CD-ROM drive in the mail, so that went in the machine too.
Now, I try a hinv and get the following:

caw2:/usr/people/bob/ hinv
2 33 MHZ IP7 Processors
FPU: MIPS R2010A/R3010 VLSI Floating Point Chip Revision: 2.0
CPU: MIPS R2000A/R3000 Processor Chip Revision: 2.0
On-board serial ports: 2 per CPU board
Data cache size: 64 Kbytes
Instruction cache size: 64 Kbytes
Secondary data cache size: 256 Kbytes
Main memory size: 64 Mbytes
I/O board, slot F: IO2 revision 2
Integral Ethernet: et0, IO2
VGX Graphics option installed
Tape drive: unit 7 on SCSI controller 0: 8mm cartridge
Tape drive: unit 6 on SCSI controller 0: 8mm cartridge
Tape drive: unit 5 on SCSI controller 0: 8mm cartridge
Tape drive: unit 4 on SCSI controller 0: 8mm cartridge
Tape drive: unit 3 on SCSI controller 0: 8mm cartridge
Disk drive: unit 2 on SCSI controller 0
Disk drive: unit 1 on SCSI controller 0
Integral SCSI controller 0: Version WD33C93A, revision 9

Here's the catch(s)

SCSI 1 is the system disk
SCSI 2 is a MAXCOMP 1.2GB disk
SCSI 3 doesn't exist
SCSI 4 is really a 8mm exabyte (MAXCOMP) 
SCSI 5 doesn't exist
SCSI 6 I think is the CD-ROM, but I've removed it from the system
SCSI 7 is a QIC-150 tape drive.

I took the system down to single user mode and did a MAKEDEV, I've cold
started it, etc, no results. I guess I could pull all but the system disk
before I reboot, just to see what happens....

Is this bad? What do I do to fix it?

TIA, Bob
------------
Bob Plested                    bob@caw2.4950tw.wpafb.af.mil
4950th Test Wing/FFXD              134.136.241.11 
Wright-Patterson AFB, OH           (513) 257-6809 DSN 787-6809

Life is too short for stop signs.
Newsgroups: comp.sys.sgi
From: kamemoto@spf.trw.com (Kenneth Kamemoto)
Subject: FAQ
Summary: FAQ desired
Keywords: FAQ
Organization: TRW Sensor Data Processing Center, Redondo Beach, CA
Distribution: usa
Date: Fri, 9 Oct 92 20:37:02 GMT

Is there a FAQ for this news group to be posted soon or
available via anonymous ftp?
-- 
Kenneth I. Kamemoto
kamemoto@spf.trw.com