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