jaap@cwi.nl (Jaap Akkerhuis) (06/24/87)
It is time to buy yet another Ethernet interface for our Vaxes. These beasts are running 4.3 WE want to know about experiences with "smart" Ethernet boards, like the Interlan (Micom) NP100 or the Excelan Exos 204. I will (of course) summarize to the net. jaap akkerhuis, jaap@mcvax or jaap@cwi.nl
henry@utzoo.UUCP (Henry Spencer) (06/28/87)
> WE want to know about experiences with "smart" Ethernet boards, like > the Interlan (Micom) NP100 or the Excelan Exos 204. I have no direct experience with these things, but I asked a similar question a while ago; perhaps a quick summary of the replies I got will suffice for this one. The general consensus was that, barring the special situation of a dumb operating system which cannot be fitted with its own networking code, the benefits of "smart" boards are doubtful. Those boards usually use relatively poor processors, e.g. the 80186, which are quite slow compared to the host. The overhead of communicating with the smart board can be quite high, to the point where it approaches the overhead of running the simpler protocols in the host itself. The protocol implementations supplied for the smart board are usually rather bare-bones versions and often have bugs. Provisions for gatewaying and internetworking are rare. You don't get sources, or the cross-compilation system you would need to make use of them. Finally, if you are running non-standard protocols as well as standard ones, the board will have to just pass the non-standard stuff through to the host, and the smart boards often don't do this very well (i.e., expect poor performance). In general, the idea seems good but the practical realizations tend to be pretty poor. They can work okay in simple situations, but they are unsuited to complex networks, and even in simple cases their throughput is often inferior to that of simple interfaces plus networking code in the host. Try (and measure) before buying. Insist on getting sources and the software needed to use them. Don't expect too much unless you're willing to add it yourself. -- Mars must wait -- we have un- Henry Spencer @ U of Toronto Zoology finished business on the Moon. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
rpw3@amdcad.AMD.COM (Rob Warnock) (07/02/87)
Henry, thank you very much for a nice summary! I have been fighting
so-called "smart" Ethernet boards for years...
Rob Warnock
Systems Architecture Consultant
UUCP: {amdcad,fortune,sun,attmail}!redwood!rpw3
ATTmail: !rpw3
DDD: (415)572-2607
USPS: 627 26th Ave, San Mateo, CA 94403burton@parcvax.Xerox.COM (Philip M. Burton) (07/02/87)
On a relatively slow machine like t PC, or even an AT, a smart Ethernet board can make a big difference in performance. I know someone who claimed that at Calma they measured a 10-to-1 difference in sustained throughput in file transfer between a dumb and a smart card. Another factor, however, is the the size of the buffer in the Ethernet card. If the buffer is too small, it will miss packets if the sending system can go at a faster rate than the PC. (That just about defines the universe-)-) ) Phil Burton Xerox Corp.
mel1@houxa.UUCP (M.HAAS) (07/03/87)
I think there are two performance factors to consider. If one wants to devote CPU cycles to Ethernet processing, then an off-board TCP/IP makes sense and high network traffic rates can be achieved. If the CPU is already burdened by having to handle too many time-share users or by just being too small, then an on-board TCP/IP makes sense (with network traffic rates limited by the board/CPU combination's power). If the on-board TCP/IP imposes more load on the CPU than an off-board TCP/IP, then something is radically wrong with the design. If anyone has evidence of such a situation, please post it here so we can avoid purchasing that board. For small systems with 80386 and 68020 class CPUs, I would think that an on-board TCP/IP with similar CPU and decent memory buffers would give optimum performance. Does anyone have figures or thoughts as to what impedes performance? One article here commented on the multiple copies being made of the data being transferred. Is that necessary or desirable? Couldn't the on-board TCP/IP processor just handle the headers on the board and DMA the data to/from user's I/O space? (i.e. no copying, just pointer shuffling) Are there TCP/IP implementations that do this? Mel Haas , odyssey!mel
jmoore@stan.UUCP (07/06/87)
In article <8212@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: > > WE want to know about experiences with "smart" Ethernet boards, like > > the Interlan (Micom) NP100 or the Excelan Exos 204. > > I have no direct experience with these things, but I asked a similar > question a while ago; perhaps a quick summary of the replies I got will > suffice for this one. > > The general consensus was that, barring the special situation of a dumb > operating system which cannot be fitted with its own networking code, > the benefits of "smart" boards are doubtful. Henry goes on with a good explanation of why the smart boards do not pan out in practice. My experiences certainly back-up this conclusion so my question is: can anyone recommend a good "dumb" Enet board for the VMEbus? The perfect board would be a full A32/D32 device with a *fast* 32 bit wide DMA path. The board should present a flexible scatter/gatter interface for direct manipulation of data from mbufs or streams. I *do not* want to run protocols on the board; I just want the board to get the data between memory and the wire as quickly as possible without causing the host to copy or reformat data. Jim Moore SAE, Longmont Colorado hao!boulder!stan!jmoore
daveb@geac.UUCP (Dave Brown) (07/06/87)
In article <585@houxa.UUCP> mel1@houxa.UUCP (M.HAAS) writes: >For small systems with 80386 and 68020 class CPUs, I would think that >an on-board TCP/IP with similar CPU and decent memory buffers would give >optimum performance. Does anyone have figures or thoughts as to what >impedes performance? One article here commented on the multiple >copies being made of the data being transferred. Is that necessary >or desirable? Couldn't the on-board TCP/IP processor just handle >the headers on the board and DMA the data to/from user's I/O space? > > Mel Haas , odyssey!mel A side point that might be of interest here: "an on-board TCP/IP with similar CPU and decent memory buffers would give optimum performance" implies that the TCP/IP board could be programmed from the host. If you have the choice of such a board, go for it. CP-6 (and possibly CP-V) has a mechanism for compiling parts of major programs (like editors) to run on the front-end processors. As a result the front ends tended to be accesable, programmable in something other than assembler and maintainable. A performance improvement was there too: the two parts of the "same" program tended to know how to communicate with each other effectively, using the basic comms primitives the system provided. Especially minimizing redundant copying. So look for boards with big ram buffers and hooks for user programmability/downloading: you may bless your foresight. -- David (Collier-) Brown. | Computer Science Geac Computers International Inc., | loses its memory 350 Steelcase Road,Markham, Ontario, | (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
henry@utzoo.UUCP (Henry Spencer) (07/06/87)
> If the on-board TCP/IP imposes more load on the CPU than an off-board > TCP/IP, then something is radically wrong with the design... Yes, the decision to use an on-board TCP/IP is a mistake! :-) Seriously, measure the overhead of talking to the board before you make such a sweeping statement. It's considerable, I'm told. And TCP/IP is not inherently a very costly protocol to implement off-board. > For small systems with 80386 and 68020 class CPUs, I would think that > an on-board TCP/IP with similar CPU and decent memory buffers would give > optimum performance... Given that we have a similar CPU and a large amount of memory, why not go for a dumb Ethernet board and a dual-CPU main processor? That's probably a better use of the second CPU. -- Mars must wait -- we have un- Henry Spencer @ U of Toronto Zoology finished business on the Moon. {allegra,ihnp4,decvax,pyramid}!utzoo!henry
sheldon@quest.UUCP (Scott S. Bertilson) (07/07/87)
I have to disagree with Henry to an extent. I have been working with the Excelan smart card at the Minnesota Supercomputer Center for about 1.5 years now and although it used to be painful, the card has been free of all but minor glitches for more than the last 6 months. We are running them on 2 VAX-11/750s (SysV.2) and have run 40 telnet sessions on one machine almost every day (this is the only commonly used access to the machine). We talked some commercial customers into looking at them and they found very significant decreases in cpu usage between the card and a Wollongong VMS implementation (primarily testing FTP). We have run the card with connections coming from the ARPAnet, across Bridge GS/3s, and from our local ethernet. The ARPAnet experi- ence showed up a number of early flaws in the firmware which were fixed. My feeling now is that it is the preferable solution for anyone who is stuck on a system that doesn't run Berkeley UNIX. The current Excelan product supplies a socket library (4.1C compatible, not 4.2 :-() which we have used to support things like MDQS and RPC in a production environment. It may only have an 80186 on board, but we have seen performance that is quite respectable when compared to anything short of a SUN-3 class machine. Scott S. Bertilson Minnesota Supercomputer Center Inc. (affiliated w/University of Minnesota) -- Scott S. Bertilson ...ihnp4!quest!sheldon or scott@uc.msc.umn.edu
lamaster@pioneer.UUCP (07/07/87)
In article <8255@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> If the on-board TCP/IP imposes more load on the CPU than an off-board >> TCP/IP, then something is radically wrong with the design... I do not think that this is correct. It takes a lot of CPU cycles to build a packet. If your system is limited to one CPU, it may make a lot of sense to offload tcp/ip somehow, especially if you are using mostly terminal servers. >Yes, the decision to use an on-board TCP/IP is a mistake! :-) Seriously, >measure the overhead of talking to the board before you make such a sweeping >statement. It's considerable, I'm told. And TCP/IP is not inherently a >very costly protocol to implement off-board. According to information from Excelan, there is almost no difference between a tty connection and Excelan on-board tcp/ip for 4.2 BSD Unix; there is a much greater overhead (on a standard test, about 10-20X) between either tty or on-board tcp/ip and 4.2 BSD pseudo-tty. Now, it all depends on a lot of factors, such as the amount of data per write, which implementation (4.2 BSD, 4.3 BSD, etc. etc.) of tcp you are talking about, to see whether it is appropriate. But, the net result is that on-board tcp-ip can be a big win. It is noted that there is a large difference in terminal controller boards also, and whether the device driver is smart enough to take advantage of the board. Interrupt-per-character boards can be even slower than a slow tcp-ip connection. Now, there may be OTHER reasons for not using an on-board tcp. Such as bug fixes and installation of new features. But, I think the performance improvement is not generally an issue. Also note that there may be other limitations that are not desirable, such as a limit of 48 tcp connections active at any one time, etc. I have done some measurements, and it is a fact that telnetd/tcp/ip is costly. Maybe not impossibly costly, but costly. In a typical editing &etc. environment with a lot of users per machine, I think you can expect to buy twice the CPU power to provide the same level of service if all your connections are via telnet/tcp/ip from a terminal server. I am not saying that you won't want to do it. There are a lot of good reasons to use terminal servers. But, it will cost you, especially if you are supporting a lot of "little" users. If you have fewer, more greedy users, tcp/ip overhead will not be an issue. I haven't done any measurements with 4.3 BSD and/or rlogin, and things may be different there. I would invite anyone who has more hard data on this to post it. >Given that we have a similar CPU and a large amount of memory, why not go >for a dumb Ethernet board and a dual-CPU main processor? That's probably >a better use of the second CPU. This is correct. Unfortunately, multi-processor Unix is still a novelty. If AT&T and Berkeley can get their multiprocessor acts together, it should be a lot easier to do this. Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "IBM will have it soon" (Disclaimer: "All opinions solely the author's responsibility")
hedrick@topaz.rutgers.edu (Charles Hedrick) (07/08/87)
Hugh LaMaster comments >According to information from Excelan, there is almost no difference between a >tty connection and Excelan on-board tcp/ip for 4.2 BSD Unix; there is a much >greater overhead (on a standard test, about 10-20X) between either tty or >on-board tcp/ip and 4.2 BSD pseudo-tty. Note that there is a lot more going on here than meets the eye. This is talking about an incoming telnet connection. That involves more than just the overhead of protocol handling. In the standard 4.2 software implementation, incoming telnet involves a separate daemon that passes data between the network and a pty. Thus characters go through three device drivers (network, pty, and tty) and a process activation in each direction (typin and echo). The actual TCP processing is a small part of the overhead. On our Pyramids, we bypass this daemon for most of the telnet conversation, by having an ioctl that crosspatches a TCP connection directly to a pty. The characters are passed between the network and the tty buffers in the kernel. (If the code detects an IAC, it returns from the ioctl, so that the daemon can still do the negotiations and other complex stuff.) This implementation gets a dramatic improvement, possibly as much as 10 to 20X. It's not just an issue of CPU time. Under moderate load, the normal telnet implementation has kind of mediocre response time. Recall that a user-level process has to be activated for each character you type and the echo. On a busy machine, the process activations and possible pageins can slow things down. Like you, I would not consider doing large-scale timesharing on a machine where most of the users came in through the normal telnetd mechanism. At any rate, the point is that the tests you quote may be confusing the benefits of offloading protocol processing with the benefits of getting rid of telnetd and pty overhead. If you want to just the benefits of offloading protocol processing, it would be better to use FTP for the tests.
geoff@eagle_snax.UUCP ( R.H. coast near the top) (07/08/87)
In article <2302@ames.arpa>, lamaster@pioneer.arpa (Hugh LaMaster) writes: > In article <8255@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: > > >> If the on-board TCP/IP imposes more load on the CPU than an off-board > >> TCP/IP, then something is radically wrong with the design... > > I do not think that this is correct. It takes a lot of CPU cycles to build a > packet. If your system is limited to one CPU, it may make a lot of sense to > offload tcp/ip somehow, especially if you are using mostly terminal servers. All of this originally started with smart boards for PC's under DOS, so let's not forget that for the average PC DOS client the metric we care about is not CPU load but response time. In the case of telnet, everything is pretty well serialized (except for really demon typists :-), so adding the overhead of (1) managing the CPU-adapter interface protocol and (2) an extra copy [difficult to avoid] really can slow things down. While it's appropriate to focus on TCP, we shouldn't ignore UDP-based services like NFS : a smart-board version of PC-NFS working with downloaded protocols would be _significantly_ slower than the dumb board version. BTW, check out the comment by Bob Metcalfe in the latest PC Week, in which he says that the benefits of a smart card have never really been demonstrated. I know 3Com offers both dumb and smart cards, but I suspect that's because some people will always buy something "smart" in preference to something "dumb".... > > >.... And TCP/IP is not inherently a > >very costly protocol to implement off-board. > This is consistent with our experience in PC-NFS. [long discussion about 4.2BSD telnetd, etc., all very true but irrelevant to the PC] > > >Given that we have a similar CPU and a large amount of memory, why not go > >for a dumb Ethernet board and a dual-CPU main processor? That's probably > >a better use of the second CPU. Distinguish also between the theoretical and the here-and-now. All of the current smart cards use 80186 or (slow) 68000 processors. This is a sufficiently price-sensitive area that it would be difficult to market a really powerful design except for server applications. Meanwhile almost all AT class CPUs are significantly faster than the smart card processor. > > Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! -- "You want a disclaimer form? Next window, please..." Geoff Arnold, Sun Microsystems East Coast Division (home of PC-NFS) UUCP: {ihnp4,decwrl,...}!sun!garnold ARPA: garnold@sun.com
geoff@eagle_snax.UUCP ( R.H. coast near the top) (07/08/87)
Ooops! Sorry 'bout my (incorrect) statement in my last posting
in which I said that the original discussion was about PC boards - I
missed the earlier postings, and the first I read was Phil Burton's
(<365@parcvax.Xerox.COM>). Fortunately I had to scan back through
the group for something else, and realized that I'd goofed.
Within the PC context, I'll stick by my comments.
Just out of curiosity, how many people run smart Ethernet
controllers on their Sun file servers?
--
"You want a disclaimer form? Next window, please..."
Geoff Arnold, Sun Microsystems East Coast Division (home of PC-NFS)
UUCP: {ihnp4,decwrl,...}!sun!garnold ARPA: garnold@sun.comlamaster@pioneer.arpa (Hugh LaMaster) (07/08/87)
In article <146@eagle_snax.UUCP> geoff@eagle_snax.UUCP ( R.H. coast near the top) writes: >not forget that for the average PC DOS client the metric we care >about is not CPU load but response time. In the case of telnet, everything > >While it's appropriate to focus on TCP, we shouldn't ignore UDP-based >services like NFS : a smart-board version of PC-NFS working with downloaded >protocols would be _significantly_ slower than the dumb board version. > >Distinguish also between the theoretical and the here-and-now. All of the >current smart cards use 80186 or (slow) 68000 processors. This is >a sufficiently price-sensitive area that it would be difficult to >market a really powerful design except for server applications. >Meanwhile almost all AT class CPUs are significantly faster >than the smart card processor. In the PC arena, I find nothing to disagree with here. Smart cards only make sense, in general (there is always an exception), on multi-user and/or multitasking systems. I didn't previously discuss ftp performance, but Excelan also has data showing that, naturally, a faster CPU with a dumb controller outperforms their board on an unloaded system, but that on a loaded system there is a significant performance advantage with a smart card. Now, there are a lot of complications here, so I would not make a blanket statement (a previous posting from Pyramid discusses some kernel mods that can change the situation), but there are fewer interrupts for the CPU to process, fewer context switches necessary, and better "scheduling" performance available to the on-board TCP/IP, which give it better performance above and beyond the result expected by looking only at available CPU cycles. So, while there is no doubt that a faster main CPU with a dumb controller will provide better "server" performance, the on-board implementation can be significantly better on a loaded multiuser system. Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "IBM will have it soon" (Disclaimer: "All opinions solely the author's responsibility")
rmarks@bbking.PRC.Unisys.COM (richard marks) (07/09/87)
Obviously if one is running a multiprocessing terminal server (eg Unix type box) you want to off-load as much TCP and IP processing to some other board. The real discussion is how well currently available boards work. My concern is the use of smart boards on a single processing remote terminal such as a PC. Is the smart Excellan board worth $600 more than the dumb 3com board (the board is $300 more but it requires an external transceiver). The Excellan salesman laughed at me when I posed this question but gave no data. 3com however, only recommends their smart board for use in servers.
romkey@mit-vax.LCS.MIT.EDU (John Romkey) (07/12/87)
In article <608@bbking.PRC.Unisys.COM> rmarks@bbking.PRC.Unisys.COM (richard marks) writes: >My concern is the use of smart boards on a single processing remote terminal >such as a PC. Is the smart Excellan board worth $600 more than the dumb 3com >board (the board is $300 more but it requires an external transceiver). I believe that Excelan has released a new version of the smart card which supports thin Ethernet. The thick-only version is called the EXOS-205. The thick-and-thin version is called the EXOS-205T. I don't know anything about the pricing, though... - john romkey
ward@cfa.harvard.EDU (Steve Ward) (07/13/87)
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
ward@cfa.harvard.EDU (Steve Ward) (07/13/87)
In the second paragraph of my posting I say ....does use a "packet timer"... I meant to say does NOT use .... the context makes that clear, I think sorry for this typo and others that may lurk in the article
brad@kontron.UUCP (Brad Yearwood) (07/14/87)
> I believe that Excelan has released a new version of the smart card which > The thick-and-thin version is called the EXOS-205T. I don't know anything > about the pricing, though... > - john romkey They're $100 more than the old boards, which means about $895 raw or with NETBIOS, $1095 with FTP and TELNET, $1175 with FTP, TELNET, and NETBIOS, $1395 with FTP, TELNET, NETBIOS, and socket programming library. I've had 3 of the 205T boards here for several weeks now. They are installed on a small Ethernet (mixed thick and thin), with thoroughly bashed and abused coax cable, and seem to talk just fine to each other and to everything else we have, using both thinwire and standard transceivers connections. Good features: Thinwire: no transceiver or multi-port needed, save $200 per node for small installations (less in cases where you have enough nodes in clusters to use multiport transceivers). Cutaway area on front edge of board makes installation reasonably simple, even with the awkward BNC connector in back. Runs fine on 10MHz bus here, has supposedly been tested past 12MHz. Yucky stuff: T-connector for thinwire can be awkward to position if you have lots of other cables on the PC back panel. (This problem is not unique to Excelan, it is a consequence of the PC back panel mechanics and electrical necessity.) Thinwire vs. thickwire selection is done by moving 7 nitty little jumpers, instead of a more convenient strap pack. But you only have to do this rarely, so big deal. Brad Yearwood Kontron Electronics {voder, pyramid}!kontron!brad Mountain View, California
klb@philabs.Philips.Com (Ken Bourque) (07/14/87)
>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. > I have had a separate problem, perhaps related. Here's the scenario: (On machine A, VMS) $ set host B (On machine B, VMS) $ telnet C ! Excelan's telnet (Machine C runs Unix) At this point I have problems. If my DECnet connection is local (Ethernet), and I cat out a long file on machine C, the terminal hangs and output characters get dropped. If my DECnet connection is via X.25 to Europe, I can't even log in to machine C! It takes over a minute to get a login prompt from the Unix machine. When I finally do, character echo times are about 20 seconds, characters are echoed in the wrong order, and the login times out before I can do anything. I am sure that the DECnet connection is not the problem. Has anyone seen anything like this?? (Excelan customer support is worthless). Ken Bourque ...!seismo!philabs!klb -or- klb@philabs.philips.com
doug@catuc.UUCP (doug) (07/14/87)
In article <620@cfa.cfa.harvard.EDU>, ward@cfa.harvard.EDU (Steve Ward) writes: > 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. I have used Excelan equipment and software for VAX/VMS. I have not used any of the application level stuff like Telnet or FTP on the machine. I implemented a proprietary protocol on top of UDP. I had never done ANY VMS programming and my success was due in a large part to their customer support. I was able to call them many times with stupid questions as well as obtain a prerelease version of a driver that fixed some bugs I had run into. My only complaint is that the people that I talked to spoke english with very difficult to understand accents.
ward@cfa.harvard.EDU (Steve Ward) (07/18/87)
Recently a new round of communications with Excelan has been opened to
address the technical problems I previously reported with the VMS Qbus
Excelan Exos TCP/IP product. Trying to be optimistic, I hope this
new round of discussions will result in a more satisfactory outcome
for all parties. Since I had expressed concerns about the Excelan
product and their handling of our customer complaints, I feel it only
fair to say that Excelan has called me to request a "fresh look" at
our concerns. I might add that I think this new response is a direct
result of others calling Excelan. I'll post the results of this
"fresh look" when they become apparent.
Steven Ward
Harvard-Smithsonian Observatory
{seismo, ihnp4}!harvard!cfa!ward
(617)495-7201