Xenix probs...

[Karl Denninger]

In article <767 at eecea.eece.ksu.edu> terry at eecea.eece.ksu.edu (Terry Hull) writes:
>In article <14 at fleet.UUCP> mel at .UUCP () writes:
>>Have you tried replacing the Computone board with another brand to see if
>>your problem continues?  Anvil Stallion cards seem to be pretty solid.
>
>Several months ago, there was a problem with the Anvil boards reported to 
>the net.  It seems they cannot take high speed input from a Trailblazer 
>uucp connection.  Has this problem gone away?  

They haven't solved the problems yet, although they keep telling me that
they have.  Now they're not calling me back again.  It's as if we're being
ignored.  I told them I would keep my trap shut for a day or two in the
middle of the week -- since they have seen fit to not return my call, here's
the scoop.

I am QUITE upset with these people.  We have two boards here -- and neither
one works right.  It's a driver problem, that much we know.  Here's a
rundown of the problems with the various drivers we have tried:

o	2.1.7 (what we use now, for reasons which will become apparent)
	Will only handle 20kbaud TOTAL ON THE BOARD for input.  A single
	19,200 baud incoming newsfeed causes output to drop to some 600 baud
	on a 2400 baud connection -- in short, performance is completely
	unacceptable.  Two telebits on the same board end up being unusable;
	you will lose connections time after time with lost packets and
	characters.  An attempt to use "rz" to receive at 19200 baud on this
	driver version will time out and puke after a few packets are sent
	-- it simply can't handle it.  Their attempt to support 38,400 is 
	a joke -- they can't even keep up with half that!  To their credit,
	9600 baud "rz"s do work most of the time, although they too drop 
	packets here and there.  TWO simultaneous 9600 baud rzs fail every 
	time.

	o Will not reload the board properly on a soft (warm) reboot, this 
	  makes autoreboots impossible, and requires a power-cycle after
	  a "haltsys" or "shutdown".


o	2.4.1, 2.4.2
	Hang at random times on 19200 and 9600 baud input.  The port just
	"goes away", but can be restarted by killing the job on the port.
	Input performance is actually _worse_ than 2.1.7 (!).  Anvil claims
	they have "no reports of trouble" with these drivers.


o	2.5 (May 25 modification date, Jeff at anvilus confirmed that this is
	current last week)
	Does strange things, including:
		o Returns EOF to uucp input requests at random times (!)
		o Decides to close the port on it's own at random times
		  during high-speed input, giving a "lost line" message from
		  uucp (!).  The line was NOT LOST -- DCD is still up at
		  that point.  The connection, though, is of course gone.
		o Refuses to drop DTR if you kill a job waiting on a modem
		  control port (ie: "ungetty /dev/tty402" leaves DTR up!).
		  Attempting to open the modem control port AGAIN, then
		  ^Cing when it hangs (because there is no DSR there!) drops
		  the DTR.
		o Dialing out on the non-modem control port after ungettying
		  without doing the machinations above (with ^C and the
		  like) appear to be operative in the first two anomolies
		  noted above.  This makes the board USELESS for shared dial 
		  in/out access on a single line, as uucp can't handle the 
		  maneuvers required.

		o Manually disabling a port, then dialing out on it using
		  Xcomm appears to work but gives gross delays on input -- 
		  if I am watching the modem lights at 2400 baud the receive
		  light on the modem goes off 1/2 - 1 second before output
		  stops appearing on the screen!  

	Anvil also claims to have no reports of problems with this version
	of the driver......

We've been putting up with missed deadlines, excuses and other nonsense for
more than seven months.  The problems, even after all this time, are NOT
fixed.  Anvil also has a philosophy problem -- they think that their
model (ie: high speed output only) is what their customers all need, and
that those of us who want to run high speed modems for input are such a 
minority that we can be safely ignored.  Needless to say, we at MCS (and I'm
sure anyone on the net feeding news!) disagree.

Anvil has been offered our assistance in resolving these problems -- we
asked for source, told 'em we'd be happy to sign a non-disclosure, and that
they would be free to use our fixes once they were complete.  They refused.

Their advertisements used to say "160,000 kb/s throughput (or something
similar)".  What they don't tell you is that their throughput claims only 
apply to output, and only if you are doing no input at all!  2.1.7, which 
is the only driver set we have (and we've got FIVE!) that is stable enough 
to use, can barely do 1/8th of that for input, 1/16th on a reliable and 
steady basis.  CPU offloading is fine, but not at the expense of reliability 
and overall usability.

When confronted with this obvious error of omission from their ad copy, they 
said "but we never claimed 160kb/s on input".  My contention is that absent 
a qualification I should be able to get 160kb/s through that card in ANY 
COMBINATION I CHOOSE -- not some special case that they have concocted to 
enhance their claims.  

Anvil's 160kb/s claim is like an automaker saying "this car will do 130 mph"
-- what they don't tell you is that it will only do 130 mph on a 60% grade
from 9,000 feet, and only for the last 1000 feet of the run!

All I want now is a refund for the boards or FIXED DRIVERS >NOW<, although 
I have a stinking suspicion we are going to end up eating them.  (To their 
credit they did at one point offer to allow us to return the boards -- 
verbally.   We have not, as of this date, been given an RA number or a formal,
written offer of a refund).  We'd love to buy something else that works, from 
a vendor that actually returns calls when they say they will, and works to 
keep customers happy.  

Digiboard comes to mind; we've begun using their cards, and are very happy 
with both their performance and support...  They actually listen to their
customer base.  Our current installations on the PC/16 are very happy, and
throughput for input is _excellent_.  Arnet also has excellent input
capabilities.  Digiboard did have some initial problems with the PC/16
drivers, but I got a diskette in the mail FIVE DAYS AFTER REPORTING
THE PROBLEM, and what do you know - the trouble was actually FIXED!

I would have kept my mouth shut if Anvil had returned my calls as promised.
They had 48 hours in which to do so, and failed.  Here it is folks.

Caveat Emptor.

--
Karl Denninger (karl at ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910]
Macro Computer Solutions, Inc.		"Quality Solutions at a Fair Price"