Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!cfa!ward
From: ward@cfa.harvard.EDU (Steve Ward)
Newsgroups: comp.dcom.lans
Subject: Re: Smart Ethernet boards
Message-ID: <620@cfa.cfa.harvard.EDU>
Date: Mon, 13-Jul-87 13:26:29 EDT
Article-I.D.: cfa.620
Posted: Mon Jul 13 13:26:29 1987
Date-Received: Tue, 14-Jul-87 05:48:34 EDT
References: <283@sering.cwi.nl> <8212@utzoo.UUCP> <8255@utzoo.UUCP> <2434@mit-vax.LCS.MIT.EDU>
Organization: Harvard-Smithsonian Ctr. for Astrophysics
Lines: 108
Summary: Warning for would-be Excelan board buyers



We have several of the Qbus Excelan boards in MicroVAX/VMS machines.

We have two MAJOR problems with the boards.  We have requested, pleaded,
and complained to Excelan, all to no avail.  Our personal experience
indicates that the Excelan customer support is less than adequate.
We have had these problems for months and months with no fixes in
sight from Excelan.

First problem:  In Telnet the board sends out characters one character
to the packet most of the time.  It appears that the board does use a
"packet timer", meaning that when a first character for a certain
destination arrives, it is buffered for a time interval (e.g. 80 ms)
and any subsequently arriving characters for that same destination
are buffered and held until the timer expires, thus allowing multiple
character Telnet packets of the characters arrive fast enough.  The
time interval is usually settable.  This buffering and timing seems
to be missing from the Excelan board.  In fact, sometimes when an
entire line is passed intact to the Excelan board Telnet, it turns
around and sends that line out one character to a packet!  It always
sends out singly arriving characters one to the packet.

This problem drastically impedes performance.  The Telnet connection
does work, though not well for obvious reasons.  Excelan has told us
that their product isn't broken, and that (telling us nicely) the
implementation details inside their product is basically not for
us to worry about, after all, it does work (their opinion, not mine)
doesn't it?

I cannot recommend this product on this problem alone.  I would love
to hear from Excelan via mail or phone, especially if they will
reconsider fixing this atrocious problem.  Excelan -- give me a call.

Second problem:  This one amusing, or would be, if I didn't need to
get it fixed.  Excelan implements binary mode (8-bit mode) in
their Telnet.  They further implement the means to enter binary
mode if it is requested from some client.  This sounds fine, except
that the Telnet RFP does not require (strictly optional) either
the Telnet client or server to implement the requesting mechanism
to enter binary mode, even though they support the binary mode.

What I have is a Bridge terminal server which supports binary mode.
At least it can be configured for binary operation through a user
interface, not needing the Telnet binary mode request mechanism to
enter binary mode.  However, the Bridge terminal server does not
implement any means to REQUEST binary mode from the Telnet server
on the other end.  Of  course, I have been told that this does
not violate the Telnet spec since the request mechanism to ask the
other end to enter binary mode is optional.  This seems unreasonable
since a terminal server seems the logical place to implement a
user interface Telnet, in general.  However, the Telnet RFP is
being complied with, no matter how stupid or illogical it may be,
and according to Bridge, that is that.  Scratch another vendor
from your list!

As you might have guessed, Excelan chose not to implement any user
interface mechanism to either enter binary mode on their Telnet or
request the other end to enter binary mode.  In my case I only need
the Excelan board to enter binary mode since I can get into binary
mode on the Bridge terminal server.  Excelan says that they have
a host server implementation and therefore should not implement
any user commands.  Sounds okay except that given the screwed up
Telnet spec. you have no way of knowing if your terminal server
or other Telnet on the other end in general, will have implemented any
means to request entering binary mode. Apparently there are more
terminal servers than the Bridge units which do not implement a
user command to request the other end to enter binary mode.  I
need either Excelan or Bridge to give me this command, but
both outfits say they conform to the Telnet spec, and begone.

Such a user command should cause the local Telnet to enter binary
mode and then request it of the end, if that Telnet responds in
the affirmative (binary mode is optional) then binary mode should
proceed.  It seems to me if the spec allows this request
mechanism to be optional even if they binary mode is implemented,
then the spec authors missed the boat.  Even so, it seems to me
a Telnet vendor would implement this request mechanism to be
safe, knowing he can't count on it being on the other end.

Well, I have a terminal server and a host Telnet, both supporting
8-bit mode and no way to get them to talk to each other in
8-bit mode.  Today's terminals, especially graphics terminals and
PC's emulating terminals, need 8-bit mode.

I cannot recommend either Bridge or Excelan on the basis of our
experience.  These problems seem simple to understand and are
probably simple to fix, but instead we have been fed, politely
but firmly, the "we are in compliance with the Telnet spec"
dogma, rather than any serious concern about the problem or
about the customer.

This is a rather long posting, but a lot of inquiries on terminal
servers and TCP/IP products for VMS have been posted lately.  I
feel this gives you some specfics that are worth airing in detail.

I encourage Excelan and Bridge to contact me directly if they
would like to discuss these matters or fix the problems.

Steven Ward (617) 495-7201

{seismo,ihnp4}!harvard!cfa!ward



of Bridge it is for the other end, in the case of Excelan there
d