🚀 go-pugleaf

In article <1992Dec16.221212.11863@umbc3.umbc.edu> David A Freeman,
dave@umbc8.umbc.edu writes:
>	I noticed that in 4.0.5F, in the file /usr/sysgen/master.d/if_ec2
>the value of the ec_rcvinit_delay variable is 13    In 4.0.5 the value 
>was 13333.  I checked with SGI and found that the correct value is 13333
>for all 4.0.X software. All of our r4000 4.0.5F systems and the
distribution 
>media that we have received have the variable set to 13. 

On our R3000 Indigo running 4.0.1 it is set to 0. Is this something I
should change?
--
Philip Machanick
Computer Science Dept, Univ of the Witwatersrand, 2050 Wits, South Africa
philip@concave.cs.wits.ac.za  phone: 27 (11) 716-3759  fax: 339-7965

In article <1992Dec17.065406.22404@shannon.ee.wits.ac.za> philip@concave.cs.wits.ac.za (Philip Machanick) writes:
>In article <1992Dec16.221212.11863@umbc3.umbc.edu> David A Freeman,
>dave@umbc8.umbc.edu writes:
>>	I noticed that in 4.0.5F, in the file /usr/sysgen/master.d/if_ec2
>>the value of the ec_rcvinit_delay variable is 13    In 4.0.5 the value 
>>was 13333.  I checked with SGI and found that the correct value is 13333
>>for all 4.0.X software. All of our r4000 4.0.5F systems and the
>distribution 
>>media that we have received have the variable set to 13. 
>
>On our R3000 Indigo running 4.0.1 it is set to 0. Is this something I
>should change?
>--
>Philip Machanick
>Computer Science Dept, Univ of the Witwatersrand, 2050 Wits, South Africa
>philip@concave.cs.wits.ac.za  phone: 27 (11) 716-3759  fax: 339-7965


this value is actually not a big deal.  it tells the HPC how long to wait
before generating an interrupt to the CPU after receiving a packet.  it
doesn't even get used under normal circumstance.  the driver looks at that
variable only when it detects some abnormal condition and switch to
promiscuous mode.  i put the change in by mistake in 4.0.5F.

In article <BzEs7E.CJ1@wm.estec.esa.nl> guy@wmsg02.wm.estec.esa.nl (Guy Brooker) writes:
>In article <1992Dec16.221212.11863@umbc3.umbc.edu>, dave@umbc8.umbc.edu (David A Freeman) writes:
> > Hello,
> > 	I noticed that in 4.0.5F, in the file /usr/sysgen/master.d/if_ec2
> > the value of the ec_rcvinit_delay variable is 13    In 4.0.5 the value 
> > was 13333.  I checked with SGI and found that the correct value is 13333
> > for all 4.0.X software. All of our r4000 4.0.5F systems and the distribution 
> > media that we have received have the variable set to 13. 
> > 
>
>
>I checked my file after reading your note, as I also have recently installed 4.0.5F. I was surprised to find that not only this entry was wrong but also the value of ec_oflow_limit. This was an error in 4.0.5(A), corrected by a release
>notes errata. THERE WAS NO SUCH ERRATA with my 4.0.5F which came with the
>indigo Video Board. I had assumed therefore that the error had been fixed, 
>aparently NOT.
>
>Whats going on SGI ?? Are there other bugs from previous releases that must	still be fixed manually ? How come old bugs creep back in ???
>
>To summarise, the if_ec2 that comes with 4.0.5F looks like this 
>
>*#ident "$Revision: 1.7 $"
>*
>* eh - SGI Hollywood/Magnum ethernet driver
>*
>*FLAG	PREFIX	SOFT	#DEV	DEPENDENCIES
>-	if_ec	-	-	bsd
>$$$
>int ec_rcvint_delay = 13;	/* delay * 30ns to recv intrpt == .4ms */
>int ec_rbuf_num = 250;		/* num of buffers to allocate to enet recv chain */
>int ec_oflow_limit = 2;		/* exceed limit of oflows/per secs => promsc mode*/
>int ec_oflow_period = 30;	/* number of seconds per oflow period */
>int ec_promisc_time = 3600;	/* number of seconds to stay in promisc mode */
>
>and it SHOULD look like this, if the errata to 4.0.5 still stands...
>
>*#ident "$Revision: 1.7 $"
>*
>* eh - SGI Hollywood/Magnum ethernet driver
>*
>*FLAG	PREFIX	SOFT	#DEV	DEPENDENCIES
>-	if_ec	-	-	bsd
>$$$
>int ec_rcvint_delay = 13333;	/* delay * 30ns to recv intrpt == .4ms */
>int ec_rbuf_num = 250;		/* num of buffers to allocate to enet recv chain */
>int ec_oflow_limit = 10000;	/* exceed limit of oflows/per secs => promsc mode*/

the errata is for people running 4DDN such that the interface won't
switch to promiscuous mode.

>int ec_oflow_period = 30;	/* number of seconds per oflow period */
>int ec_promisc_time = 3600;	/* number of seconds to stay in promisc mode */
>
>I have had some problems with my ethernet since the new installation, and since
>changing to above they seem so far to have gone completely...

what sort of problem ?

>
>Guy
>
>-- 
>
>-------------------------------------        	Guy Brooker
>Internet: guy@wm.estec.esa.nl        		European Space Research and
>	  guy@wmsg02.dnet.estec.esa.nl		Technology Centre (ESTEC)
>	  gbrooker@estec.esa.nl
>Bitnet  : gbrooker@estec.bitnet		SPAN    : ESTERS::GUY
>Phone	: +31-1719-83611		Fax	: +31-1719-85617
>Mail	: ESTEC JW/WMS, Keplerlaan 1, 2200AG NOORDWIJK, The Netherlands

In article <tnj3980@zuni.esd.sgi.com>, dwong@sgi.com (David Wong) writes:
 > In article <BzEs7E.CJ1@wm.estec.esa.nl> guy@wmsg02.wm.estec.esa.nl (Guy Brooker) writes:
 > 
 > the errata is for people running 4DDN such that the interface won't
 > switch to promiscuous mode.
 > 
 > >
 > >I have had some problems with my ethernet since the new installation, and since
 > >changing to above they seem so far to have gone completely...
 > 
 > what sort of problem ?
 > 

My machine occasionly lost contact with the NFS server, sometimes breifly, sometimes over extended periods, and allways with the News server breifly as information is requested. 

Since making the two changes I mentioned, I have not seen these problems.

I was running 4DDN, but have switched it off scince 4.0.5F. 

Guy

-- 

-------------------------------------        	Guy Brooker
Internet: guy@wm.estec.esa.nl        		European Space Research and
	  guy@wmsg02.dnet.estec.esa.nl		Technology Centre (ESTEC)
	  gbrooker@estec.esa.nl
Bitnet  : gbrooker@estec.bitnet		SPAN    : ESTERS::GUY
Phone	: +31-1719-83611		Fax	: +31-1719-85617
Mail	: ESTEC JW/WMS, Keplerlaan 1, 2200AG NOORDWIJK, The Netherlands

In <BzGAyF.HFK@wm.estec.esa.nl> guy@wmsg02.wm.estec.esa.nl (Guy Brooker) writes:

>My machine occasionly lost contact with the NFS server, sometimes breifly, sometimes over extended periods, and allways with the News server breifly as information is requested. 

>Since making the two changes I mentioned, I have not seen these problems.


I was having the same type of problems, as evidenced by the scrolling of  
	NFS server <name> not responding still trying
	NFS server <name> ok"
in my console window and the SYSLOG, as well as the giant pauses as I tried 
to access the NFS mount.  I am running IRIX 4.0.5, too, so I looked at the
/usr/sysgen/master.d/if_ec2 file and found the same thing.  So I changed
the value of int ec_rcvint_delay to 13333 and the value of int ec_oflow_limit
to 10000 (as suggested by the previous post) and haven't seen the NFS 
problems, yet!

So, what gives?  Is this something I should look for and change on all my 
SGI systems?  It seems to make a difference in a heavy NFS-use environment.


Amy


--
=========
Amy K. Swanson
SGI Systems Administrator, NCSA
amys@ncsa.uiuc.edu