From:	CSBVAX::MRGATE!cetron%ced@cs.utah.edu@SMTP  4-JAN-1988 13:35
To:	ARISIA::EVERHART
Subj:	Re:  TCP Request


Received: from cs.utah.edu by C.CS.CMU.EDU with TCP; Mon 4 Jan 88 12:44:45-EST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
	id AA09825; Mon, 4 Jan 88 10:41:12 MST
Received: by ced.utah.edu (5.54/utah-1.0-slave)
	id AA02740; Mon, 4 Jan 88 10:46:00 MST
Date: Mon, 4 Jan 88 10:46:00 MST
From: cetron%ced@cs.utah.edu (Ed Cetron)
Message-Id: <8801041746.AA02740@ced.utah.edu>
To: HANWAY@lids.mit.edu
Subject: Re:  TCP Request
Cc: cmu-tek-tcp@c.cs.cmu.edu


	yep, sounds familiar.... seems there is this bit returned by a 
get status call to the xe, xq  driver.  It was originally used by the dmdriver
to indicate when a foreign computer was unresponsive, so it was given
the name xm$m_sts_timo (for timeout...).  When the xedrv.bli part of the
ipacp wants to check for the results of qio's to the xedriver (part of vms)
it checks for errors including checks for xm$m_sts_active, and xm$m_sts_orun
(for over-run).  Obviously, under normal circumstances, a return of 
xm$m_sts_timo would be a fatal error.  Unfortunately, the load that a LAVC
puts on the deqna (and I presume the vs2000 equivalent) is quite heavy, and
so LOTS of _timo status returns are generated.

	I simply decided to try ignoring them and see what happens. Lo and
behold, it works just fine.  While there is some probability that ignoring
the _timo bit WILL miss a TRUE error, in 9 months of running, I have yet
to notice it. 

	the patch:

		in xedrv.bli, change all occurences of FF00 to FD00, this
will cause all status checks to ignore xm$m_sts_timo.

Good luck...

-ed cetron
cetron@cs.utah.edu