latzko@zydeco.rutgers.edu (Alexander Latzko) (10/17/88)
Well, Having some netware and a large amount to IP around here ( Rutgers U ) has lead me to some astonishing conclusions: 1> Boards which do TCP on board are generally a waste of time and effort. The two which I have handy to gripe at are the EX205T and the UB PCNIU. 2> The Micom/Interlan Gateway lists for $3995 and has performance limitations. You also probably don't want to use it in anything smaller than a 386. 3> Packet drivers are available and work well. Basically this will let you use your favorite TCP and Novell on the same workstation with a much less expensive card since the software does the work. Several companies sell this but as far as I can tell the bottom line is everyone is buying the TCP from FTP Inc. This is the path I have chosen here for our Netware networks which might want to speak IP. The ethernet card we use here it the Micom NI5210-8 although Western Digital told me to expect theirs before the end of 88 for the WD EtherCard Plus. cheers /S* As always please send comments and barbs to latzko@rutgers.edu {backbone}!rutgers!latzko PS. Standard Disclaimer... I neither work for nor receive payment from Interlan, WD or FTP INC. Micom Interlan FTP Inc Excelan WD and Ungermann Bass are trademarks probably owned by someone
dannyb@kulcs.uucp (Danny Backx) (10/19/88)
In article <Oct.16.15.09.26.1988.269@zydeco.rutgers.edu> latzko@zydeco.rutgers.edu (Alexander Latzko) writes: >Having some netware and a large amount to IP around here ( Rutgers U ) >has lead me to some astonishing conclusions: > >1> Boards which do TCP on board are generally a waste of time and >2> The Micom/Interlan Gateway lists for $3995 and has performance >limitations. You also probably don't want to use it in anything >smaller than a 386. >3> Packet drivers are available and work well. Basically this will >let you use your favorite TCP and Novell on the same workstation >with a much less expensive card since the software does the work. Could you provide us with some explanation of these statements? Especially (1) seems to be the direct opposite of what everybody claims: that the host OS can be relieved of a lot of work with TCP on a board. Danny Backx -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Danny Backx | mail: Danny Backx Tel: +32 16 200656 x 3544 | Katholieke Universiteit Leuven Fax: +32 16 205308 | Dept. Computer Science E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A ... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven dannyb@blekul60.BITNET | Belgium
latzko@zydeco.rutgers.edu (Alexander Latzko) (10/22/88)
In article <132@icarus.kulcs.uucp> dannyb@kulcs.uucp (Danny Backx) writes: > In article <Oct.16.15.09.26.1988.269@zydeco.rutgers.edu> latzko@zydeco.rutgers.edu (Alexander Latzko) writes: > >Having some netware and a large amount to IP around here ( Rutgers U ) > >has lead me to some astonishing conclusions: > > > >1> Boards which do TCP on board are generally a waste of time and > >2> The Micom/Interlan Gateway lists for $3995 and has performance > >limitations. You also probably don't want to use it in anything > >smaller than a 386. > >3> Packet drivers are available and work well. Basically this will > >let you use your favorite TCP and Novell on the same workstation > >with a much less expensive card since the software does the work. > > Could you provide us with some explanation of these statements? > > Especially (1) seems to be the direct opposite of what everybody claims: that > the host OS can be relieved of a lot of work with TCP on a board. 1> I realize I shouldn't generalize but occasionally it looks safe in context. It depends on what the host processor is and what the processor on the card is. If the host processor is a 386 and the processor on the card is a 186 or a slow 286 then under DOS ( which is where these comments are pointed ) it will indeed slow the system down. Moreover, the implementations of TCP I have seen for the embedded cards haven't been nearly as good as for dumb cards. Under a true multitasking operating system which knows how to block io they can be a win. Novell is a multitasking OS and I will admit to using Micom NP600A cards in 286 servers. 2> The Micom/Interlan gateway does indeed list for US$3995. It is limited in the number of IP connections it can maintain. The last time I looked to would only handle 24 connections. In a fairly large network this is simply not enough. The last time I saw one in action it was chewing up over 10% of the cpu on a compaq 386/16 for 4 telnets. Unfortunatly, I didn't get a chance to see if that was a constant. I suspect Larry Backman of Interlan will come breating down my neck if I am too far off the mark. I expect it will get better as time goes on ( it has improved remarkably in the last year and development continues ) so I would like to be proven wrong. For someone who had an installed base of some random network interconnect and won't be heavy IP users it is the only solution. 3> Packet drivers are low level device drivers which pass information to more than one active job. Simply put you load the device driver as you normally would. Then instead of only talking to IP or IGX it speaks to both. Nifty, eh what. The list of companies which have packet drivers is much longer than I may have implied, here are all the ones I know of: Micom/Interlan, Sytek, Western Digital,Proteon, BICC,and Torus. > Danny Backx | mail: Danny Backx > E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A cheers /S*
ron@ron.rutgers.edu (Ron Natalie) (10/23/88)
1. It's a crime to put $1000 of networking hardware in a $2000 PC. 2. If the OS is MS/DOS, then it isn't multitasking anyway and the 286 on the CPU board isn't likely to be running while you're using the 286 on the interface card. 3. When you buy a generic dumb card you can get software and updates from any number of places. For example, I know of two public domain and at least four commercial TCP products for PC's. None of these supports any of the smart cards (they would not be big sellers). I've got two different smart cards (Excelan and UB). Neither are terribly useful because they're software is so out of date. I can go out and buy stuff for any of the dumb cards that works 100% better. -Ron
backman@interlan.UUCP (Larry Backman) (10/27/88)
In article <Oct.21.13.38.50.1988.528@zydeco.rutgers.edu> latzko@zydeco.rutgers.edu (Alexander Latzko) writes: >> >1> Boards which do TCP on board are generally a waste of time and >> >2> The Micom/Interlan Gateway lists for $3995 and has performance >> >limitations. You also probably don't want to use it in anything >> >smaller than a 386. > > >2> The Micom/Interlan gateway does indeed list for US$3995. It is >limited in the number of IP connections it can maintain. The last >time I looked to would only handle 24 connections. In a fairly large >network this is simply not enough. The last time I saw one in action >it was chewing up over 10% of the cpu on a compaq 386/16 for 4 >telnets. Unfortunatly, I didn't get a chance to see if that was a >constant. I suspect Larry Backman of Interlan will come breating down >my neck if I am too far off the mark. I expect it will get better as [] Hpoe I'm not breathing too hard... However, we argue the smart board dumb board, gateway question a lot here; so. a few points to ponder.. 1. Generally speaking, a smart board can match an 8 or 10 MHz. AT in performance. Our smart board as well as others can actually out-perform an equivilent speed AT running the same code. Why? The smart board has some sort of communication oriented OS that is dedicated to two things, responding to host requests, and picking packets off of the wire. This OS does not have to deal with keyboards, screens, disks, etc.. 2. Smart boards save host memory. This is a big win in DOS-land; not so important in UNIX, OS/2, and other protected mode OS's. 3. Smart boards cost more, and have memory which cannot be used outside of communications. 4. Dumb boards and host based protocols clearly out-perform the same protocol on a smmart board as soon as tou move into the 80386 family. I have an ISO-NETBIOS protocol stack that runs in both DOS and OS/2 on both smart and dumb boards. On a 386-16 the host based protocol stack is 70% faster than the board based protocol stack, on a 386-20 it was 120% faster; I have not measured a 386-25 yet. 5. Gateways are not for everyone. They do a lousy job of serving heavy TCP user's. On the other hand, they do a great job of serving the casual TCP access most PC user's seem to need. No, a gateway will not help 20 users who wish to spend 80% of the time doing keyboard intensive TELNET apps. It will help a workgroup of 30 or 40 users who do casual TELNET, FTP, and SMTP access, casual being defined as less than 33% TCP usage. 6. A well-designed gateway provides minimal disruption of the host CPU. I believe that the CPU usage you saw with 4 TELNET's would be duplicated by those 4 Novell workstations doing any sort of continous file server access using IPX. Gateway's (and for that matter, all intelligent boards) are nice in that they remove the Ethernet receive function from the host. All those broadcasts that IP drops, all those keepalives that TCP drops never make it up to the host. A dumb board, with a host based protocol stack, can swamp even the fastest host, provided the network has a lot of traffic. This argument is fun, its one of those religious wars that has no correct answer. Another good one (next time) is the correct hardware architecture needed to do fastt protocols. Larry Backman Interlan, Inc.
brad@interlan.UUCP (Brad Kemp) (10/27/88)
One point that has not been brought up in this discussion of the advantages of dumb over smart cards is the topology of the network in question. Although end to end throughput may be slower using an intelligent processor on a fast machine (i.e 80386, 68030 etc...) this should not be the only concern when making the dumb vs. smart choice. Some networks produce an astonishingly high amout of broadcast noise. This is especially true when multiple protocols are run over the same media. The host must deal with each of these recieve interrupts and determine if the packet is for it. This consumes host resources and lowers the total work capacity of the host since packets are recieved regardless of whether the user(s) are using the network or not. A compromise on fast machines seems to be using an intelligent data link controller. The fastest version of TCP/IP we run here uses a smart card as a data link controller. This frees the host from servicing extranious noise since packet filetering is done in the controller yet lets the speed of the host meet the end to end throughput requirements of faster machines. This also reduced the CPU time spent on protocol processing by 50% vs. the dumb card implementation. Of course previous points have been made when the host is multi-user but even here the topology should be taken into account. Some fast implementations of protocols are sutible for a host based solution on fast machines, others are not. If the network has many short lived connections, establishment and release of connections can eat host cycles. Here it may be a better idea to use a smart implementation. These arguments over Smart vs Dumb can become as religious as TCP vs ISO or Intel vs. Motorola. It is best to look at what you want to accomplish and make your choice based on your own environment. Brad Kemp Interlan, Inc. {ulowell,mit-eddie}!interlan!brad brad@interlan.UUCP