jonm@killer.UUCP (Jon Meinecke) (11/13/87)
I would like to hear your informed comments and comparisons (both anecdotal and empirical) of various IBM-PC local area network software and hardware. I am particularly interested in comparisons of "throughput" for the Novell NetWare systems on various network interface hardware including token ring, Ethernet, and Starlan IBM-PC compatible adapter boards. Please include any comment regarding product reliability and support as well as network media, cabling schemes and topology. Respond by e-mail and I will post a summary of the responses. Thanks, Jon Meinecke ...ihnp4!killer!jonm
gardner@kodak.UUCP (dick gardner) (11/16/87)
In article <2070@killer.UUCP> jonm@killer.UUCP (Jon Meinecke) writes: > > > >I would like to hear your informed comments and comparisons >(both anecdotal and empirical) of various IBM-PC local area network >software and hardware. I am particularly interested in comparisons >of "throughput" for the Novell NetWare systems on various network >interface hardware including token ring, Ethernet, and Starlan >IBM-PC compatible adapter boards. > A few months back, either PC magazine or Byte, I can't remember which, had an issue devoted to LANs. It provided a lot of information. (I could look back and see which magazine and what issue, if it's important) But the point I wanted to make was that I sent in the reader's card with a lot of numbers circled for more information. I received lots of Madison- Avenue type stuff from several manufacturers, but the the best REAL info came from Novell. They sent me a package which must have weighed 3-4 pounds and must have cost them a fortune to mail! Included was a LAN Evaluation Report and a LAN Software Evaluation Report, which I now use as a sort of LAN Bible. I felt that it was a reasonably objective report detailing all the things (I think) you want to know. Of course, it also contained Novell Product information, but that's to be expected. I suggest you try to get a copy of that report from Novell, and I think it will be very helpful. =#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=# Dick Gardner -- Eastman Kodak Co. Rochester, New York 14650 Phone: (716) 477-1002 UUCP: {allegra,rutgers}!rochester!kodak!gardner "Oh yeah?!? Well, MY computer is SOOOOO FAST, it executes an infinite loop in 6 seconds!!!" =#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#=#
alan@cunixc.columbia.edu (Alan Crosswell) (11/16/87)
Let me throw my two cents in and also say that I found the Novell docs to be excellent sources of technical overview information. It is refreshing to read something like this when the typical PC LAN vendor doesn't even know that their hardware can be used for more than just their software. (A case in point, not meant to be cruel -- the marketing person simply didn't have the appropriate technical support behind her -- is how a year ago we had to explain to our UB rep that you really can use their PC NIC card for other than Net/One.) I think most of us know how to read a vendor-produced document with a grain of salt. Even if you never buy NetWare or any other PC LAN implementations, you should get the reports. One item to note is that they do have performance comparisons that are now out of data w.r.t. IBM LAN software (and probably the others as well) since there have been one or two new releases since the publication date. IBM claims to have made substantial performance improvements in these releases. Take that with a grain of salt too! /a
ruiu@tic.UUCP (Dragos Ruiu) (11/17/87)
In article <1020@kodak.UUCP>, gardner@kodak.UUCP (dick gardner) writes: In article <2070@killer.UUCP> jonm@killer.UUCP (Jon Meinecke) writes: >I would like to hear your informed comments and comparisons >(both anecdotal and empirical) of various IBM-PC local area network > > But the point I wanted to make was that I sent in the reader's card with > a lot of numbers circled for more information. I received lots of Madison- > Avenue type stuff from several manufacturers, but the the best REAL info > came from Novell. They sent me a package which must have weighed 3-4 > pounds and must have cost them a fortune to mail! Included was a LAN > Evaluation Report and a LAN Software Evaluation Report, which I now use > as a sort of LAN Bible. I felt that it was a reasonably objective report > Dick Gardner -- Eastman Kodak Co. Rochester, New York 14650 > Phone: (716) 477-1002 > UUCP: {allegra,rutgers}!rochester!kodak!gardner I too agree that the Novell report was an unusually useful response to a bingo card.... It is very comprehensive. It covers the majority of the hardware and software vendors that were available when it was written very objectively, and the information is well organized. However, I had great difficulty believing their hardware section, which repeatedly says that DMA interface boards are slower than others. Unless there is something I don't know, DMA is much faster than interrupt driven hardware. I have not had the time or the resources to research their claims, but common sense would indicate that this claim of theirs is way off base. This inaccuracy made me wonder what else was wrong in their report. Anyone care to comment ? -- Dragos Ruiu Disclaimer: My opinons are my employer's, I'm unemployed! UUCP:{ubc-vision,mnetor,vax135,ihnp4}!alberta!edson!tic!dragos!work (403) 432-0090 #1705, 8515 112th Street, Edmonton, Alta. Canada T6G 1K7 Never play leapfrog with Unicorns...
rpw3@amdcad.UUCP (11/19/87)
In article <155@tic.UUCP> ruiu@tic.UUCP (Dragos Ruiu) writes: +--------------- | I too agree that the Novell report was an unusually useful response... | However, I had great difficulty believing their hardware section, which | repeatedly says that DMA interface boards are slower than others. Unless | there is something I don't know, DMA is much faster than interrupt driven | hardware. +--------------- Surprisingly, not always! I have seen many cases over the years where a clean-and-simple interrupt-driven design beat out a DMA design, especially when the DMA hardware was clumsy, hard to set up and get started, and hard to re-start. The PC's DMA chip loses on all counts in my book, but you can't do DMA without it, since the bus doesn't let peripherals do "true DMA". (This is partially fixed in the -AT, and even more so in the PS/2.) DMA can also be a loser is "low latency" applications, where getting to the data quickly is more important than moving bulk along, especially when the hardware must be touched in "realtime" to make some protocol work (as is often the case in 3270 bisync, for example). "It ain't that simple" is one of the variants of Murphy's Law. The design dimensions of low latency, throughput, and CPU overhead are ALWAYS mutually antagonistic, if not exclusive. Using DMA well requires a bus design that supports multiple bus masters, with low overhead switching from one to another. Few low-cost computers have such a bus. I don't know whether Novell is simply touting THEIR particular design, or whether they've done a careful analysis and decided that DMA just isn't worth it for a typical LAN controller (provided you have sufficient on-board buffer and a simple way to map the buffer pages into memory). I do know they COULD be right, based on situations I've seen before... 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 94403
mrc@CAM.UNISYS.COM.UUCP (11/19/87)
In article <155@tic.UUCP> ruiu@tic.UUCP (Dragos Ruiu) writes: >...long referral trail deleted... >... > However, I had great difficulty believing their hardware section, which >repeatedly says that DMA interface boards are slower than others. Unless there >is something I don't know, DMA is much faster than interrupt driven hardware. >... First, which of the following are we asking?... "Is MY workstation trans-net access speed lower with a DMA netcard?" or "Is the net aggregate thruput lower with DMA netcards on the workstations?" or "...?" Usually, I think, most instances considering a net of more than just a couple workstations tend to concentrate on the second question. Or, when they do address the first question, they tend to look at it in terms of transfer rate during (or elapsed time for) rather large chunks of data (i.e. umpty-KB). Well, humm, having been embogged (emboggled?) in this kind of issue just a few times ago... The type of netcard (DMA vs. interrupt-and-read) has nothing to do with aggregate net thruput if the product line is anywhere close to good. This is not to say that there is no difference between product lines, it is just saying that it takes a pretty damn bad design for ONLY netcard-to-CPU transfer mode to have a notable differential effect on the net as a whole. The type of netcard (DMA vs. i-&-r) need not have much, if any, effect on the burst/block rate of the workstation IF the upper layers (NETBIOS- equivalent, and above) are a clean implementation of the "right" protocol for the job. Trap-and-overlap, or whatever it may be called, can keep the workstation "ready" with respect to the net, with either type of netcard. It's just a matter of HOW those mid-layers are implemented. Now, again, let's get back to the first question, with the emphasis on the term MY... The Novell folk are smart enough to know, and they do know, that what sells a network, or keeps it sold, is what it does for those poor peons whom we gurus tend to neglect (to put it kindly). When I/me/myself is the user; when I am doing the explicitly or implicitly transaction-ish stuff that really occupies most of the on-terminal time of most folk like me--then what counts is "How fast does MY SCREEN SHOW the next thing I want to see?" Here is where, to some folks' surprise, an interrupt-and-read type netcard can substantially beat a DMA type netcard. This is because so much of the transaction-ish applications are treating the data from (and often, to) the net as a stream of individually relevant characters (at least, as individually partly processable before the whole block has arrived and/or as maybe actually going to arrive in multiple blocks, anyhow). This means that the user ends up seeing something (often, actually, something "useful") quite a bit sooner. Now, for all of those self-appointed gurus who have just written-off this whole missive as too much like social science and not sufficiently arcane or academic-ish, all I can say is that I have been bitten on the backside more than once in the process of learning this. And, if the data were not "company black" to a couple of clients I have had, I could show you a couple of very interesting simulations AND TRACES OF REAL SYSTEMS (shame on me for mentioning the real world?) which proved the thesis above--much to the chagrin of those of us who were trying to disprove it! "Whosoever pisseth in the beer is not entitled to complain of strange flavor." Froggy Best regardz, Ken Leonard
arnaud@schizo.dec.com.UUCP (11/20/87)
> I too agree that the Novell report was an unusually useful response >to a bingo card.... It is very comprehensive. It covers the majority of >the hardware and software vendors that were available when it was written >very objectively, and the information is well organized. > However, I had great difficulty believing their hardware section, which >repeatedly says that DMA interface boards are slower than others. Unless there >is something I don't know, DMA is much faster than interrupt driven hardware. >I have not had the time or the resources to research their claims, but >common sense would indicate that this claim of theirs is way off base. > This inaccuracy made me wonder what else was wrong in their report. Anyone >care to comment ? Novell is right, DMA on an AT is slower thatn PIOs, the 286 will move data faster than the 8237 DMA controller. The Apollo DN3000 has a PC-AT type bus, and the Token Ring Adapter uses 68020 PIOs to move the data.
henry@utzoo.UUCP (Henry Spencer) (11/23/87)
> ...I had great difficulty believing their hardware section, which > repeatedly says that DMA interface boards are slower than others... > DMA is much faster than interrupt driven hardware. Well... it depends. There are really *three* flavors of hardware here: interrupt-per-character, DMA, and internally-buffered, to give them vaguely accurate names. Internally-buffered stuff often brings its internal buffer out as dual-ported memory, although that isn't logically necessary. The difference between DMA and buffered is just who does the data copying, peripheral or CPU. Interrupt-per-character stuff *is* slow. The tradeoffs between DMA and buffered are much less clear. In principle DMA can be better. In practice, complications like bus acquisition and just plain badly-designed hardware often make buffered competitive or even superior. Modern CPUs are pretty good at copying data. -- Those who do not understand Unix are | Henry Spencer @ U of Toronto Zoology condemned to reinvent it, poorly. | {allegra,ihnp4,decvax,utai}!utzoo!henry
truett@cup.portal.com (11/24/87)
While discussing DMA versus PIO devices on PCs, let me add the following little tidbit which I discovered working on a piece of hardware that used DMA. Most DMA devices designed for PCs assume an 8-bit peripheral interface, so they assume the DMA is an 8-bit DMA, which it is on the PC or XT. In that case it takes 5 bus cycles, or 1.05 microseconds at 4.77 MHz, to move one byte. Now the 8-bit DMA channels of an AT are cascaded through one of the 16-bit DMA channels, so it takes 10 bus cycles to move one byte through an 8-bit DMA access peripheral on the AT. Yes, a 16-bit peripheral connected directly to the 16-bit channel only takes 5 bus cycles to move 2 bytes. But the effect is, for 8-bit peripherals attached to the 8-bit DMA channels, that any AT operating at less than about 9.8 MHz moves the data more slowly than the lowly XT at 4.77 MHz! The moral? On an AT, PIO is faster than DMA, especially if your I/O device can handle the OUTSW instruction at full speed. Even OUTSB is faster.pa As far as I know, none of the technical documentation from IBM takes the trouble to mention this. I only found out when a peripheral made by the company I work for which was optimized for the XT using DMA failed miserably to run on a true blue AT but did on some clones which had different DMA arrangements. We finally ended up using dual-ported memory because some I/O circuits are very slow on some machines. Truett Smith, Sunnyvale, CA UUCP: truett@cup.portal.com