schoff@cadmus.UUCP (Martin Lee Schoffstall) (10/10/84)
In the October issue of BYTE IBM has an advertisement and specification
of this new networking capability. They say they are using the Intel
82586 processor. I thought that this was an ethernet processor? Are they
really using an off the shelf 82586 or is it a special just for IBM from
Intel? Would anyone care to comment.
marty
cadmus!schoff@seismo.ARPA
{bbncca,wivax,linus,seismo}!cadmus!schoffwmb@sun.uucp (Mitch Bradley) (10/11/84)
> In the October issue of BYTE IBM has an advertisement and specification > of this new networking capability. They say they are using the Intel > 82586 processor. I thought that this was an ethernet processor? Are they > really using an off the shelf 82586 or is it a special just for IBM from > Intel? Would anyone care to comment. > > marty The 82586 can do more than just ethernet. It has programmable parameters for just about everything, and can run at bit rates lower than 10 MBits/sec. It can do bit-stuffing protocols as well as ethernet-style protocols. At lower bit rates, it even will do the Manchester encoding for you. The default set of parameters implements the Ethernet spec. A CONFIGURE command lets you change the parameters. It looks like Intel was planning on using the part to talk to the serial bus that is part of the Multibus II spec. Mitch Bradley
rpw3@redwood.UUCP (Rob Warnock) (10/12/84)
+--------------- | In the October issue of BYTE IBM has an advertisement and specification | of this new networking capability. They say they are using the Intel | 82586 processor. I thought that this was an ethernet processor? +--------------- It is. +--------------- | Are they really using an off the shelf 82586 or is it a special just for | IBM from Intel? Would anyone care to comment. | marty / cadmus!schoff@seismo.ARPA / {bbncca,wivax,linus,seismo}!cadmus!schoff +--------------- <Oh boy, I haven't had an excuse to really flame for a while!> <<FLAME ON!>> Having not seen the article (but I'm gonna go get it!), I can't be sure, but if you look at the 82586 chip spec (which I HAVE done, in detail) you will see that it's a typical overengineered "Well as long as we're building a chip let's throw everything in!" multi-purpose hunk of silicon (and no wonder it took them so long to make it work). ((In fact, last time I looked, it STILL wasn't working at 10 Mbit/s, but surely they've fixed that by now, haven't they? ;-} Can someone tell me? )) Despite the fact that Intel was one of the co-authors of "the" Ethernet Spec, this chip shows a remarkable lack of committment to Ethernet, per se. In particular, nearly EVERY parameter of what makes an Ethernet be "Ethernet" is "tunable". (Sometimes it seemed to me to be simply because it was POSSIBLE to set it in software, not that anyone would ever change it from the "Ethernet" defaults. However, it's more likely that the chip is a "committee camel", with something for everyone.) Besides running at 10 Mbit/s, it will run at rates down to 1 Mbit/s and below. You get several flavors of collision handling, several kinds of backoff, choice of CRC-16 or Ethernet/802.3 CRC-32, Manchester or NRZ, etc, etc. It will even do SDLC-style bit-stuffing instead of Ethernet-style carrier-detect. From the Intel LAN Component User's manual: "The 82586's programmable network parameters allow it to to serve as controller for a wide range of CSMA/CD type LAN's. It is compatible with network specifications such as high service (broadband), high performance (short topologies), and low-cost (1 Mbps) networks. Data rates less than 10 Mbps are supported. Many parameters are configurable including all framing parameters (i.e. address length, End-of-Carrier or Bitstuffing frame boundary delineation, etc.), Slot Time and Interframe Spacing." [p. 2-1] "...station priorities are also programmable." [p. 2-4] "...two priority mechanisms: linear and accelerated contention resolution." [p. 2-4] If you get the impression that it's not one of my favorite chips, you're right. It's simply too complex. The best part about it is the buffer handling (you can separate the transmit header from the body), but the Mostek/AMD "Lance" has all of the needed functionality in the buffer handling area (including command and data chaining) but is a lot simpler to use. (The "Lance" was clearly built to do Ethernet. Period. Like UNIX tools: "Do one thing well.") ((Of course, I still like the Seeq chip: the first "Ethernet UART"! (UERT?))) Surprisingly, the one configurable parameter that is needed desperately is missing. The "Lance" lets you select Big-Endian vs Little-Endian byte order within a 16-bit word ("byte swap" or not on transmit/receive data, without affecting command descriptors), a feature that the 82586 sorely needs when handling DoD/IP or XNS (both of which are "Big-Endian"). The 82586 is "optimized for operation with the iAPX 186 bus [80186] but can be used with other general purpose processors." [p. 2-2] It's gonna be REAL fun to use with a 68000... ;-} Someone PLEASE correct me if I am wrong on this point, as it is critical to avoid the overhead of swapping bytes in software before/after you transmit/receive. Although I looked through the User's Guide and the Data Sheet carefully, I found no mention of byte order, except one very clear picture of the address bytes which shows it to be "Little-Endian" (the first byte sent is bits 7-0, the second byte is 15-8, etc.). It may very well be that the only reasonable way to use the 82586 (even with a 80186) is to reverse the high and low bytes in the wiring of the board, though this will totally confuse the programming of the control and descriptor blocks (which contain addresses in them). Still, it is perhaps better to do that than to flip all the data. <<FLAME OFF>> Given IBM's close connection with Intel, it is perfectly reasonable for them to use the 82586 for a "low-cost" net, since their buying power WILL bring the chip price down (to them). I still contend, however, that when all is said and done, the FCC satisfied), and all of the indirect costs included, a properly balanced Ethernet subsystem need not cost significantly more than a "low-cost" net. I am also concerned that the PC network may not be as convenient for supporting DoD/IP or XNS as we might wish. Rob Warnock UUCP: {ihnp4,ucbvax!amd}!fortune!redwood!rpw3 DDD: (415)572-2607 (*new*) Envoy: rob.warnock/kingfisher USPS: 510 Trinidad Ln, Foster City, CA 94404 (*new*)
kho@hou2a.UUCP (S.KHO) (10/13/84)
Intel 82586 is a chip is an Ethernet Data Link Controller. It implments the CSMA/CD media access protocols, provides 16 or 32 bit CRCs, allows 16 to 128 bits for preamble, variable address length, variable speed and eight level priority mechanism. It is usally designed to used with Intel 82501 which handles the coding/encoding, clocking and interface to the transceiver. The price is going down fast. It costs around $65 in 1983. I suspect that it's around $30 now.
skip@gatech.UUCP (Skip Addison) (10/13/84)
> In the October issue of BYTE IBM has an advertisement and specification > of this new networking capability. They say they are using the Intel > 82586 processor. I thought that this was an ethernet processor? Are they > really using an off the shelf 82586 or is it a special just for IBM from > Intel? Would anyone care to comment. > > marty > > cadmus!schoff@seismo.ARPA > {bbncca,wivax,linus,seismo}!cadmus!schoff The 82586 processor handles mainly the media access protocols (I think). Since the Sytek network is CSMA/CD, all they have to do is put different serial encoder on and they have a broadband network. The reason they can use CSMA/CD on a rather large CATV plant is the data rate on the broadband channel is only 128kbps (assuming it is the same as the Sytek Localnet 20 product line). -- from the DMZ of Skip Addison The Office of Telecommunications and Networking Georgia Tech, Atlanta GA 30332 CSNet: Skip @ GATech ARPA: Skip.GATech @ CSNet-Relay.ARPA uucp: ...!{akgua,allegra,amd,hplabs,ihnp4,seismo,ut-ngp}!gatech!skip
wmb@sun.uucp (Mitch Bradley) (10/14/84)
Regarding the Intel 82586 > (and no > wonder it took them so long to make it work). ((In fact, last time I looked, > it STILL wasn't working at 10 Mbit/s, but surely they've fixed that by now, > haven't they? ;-} Can someone tell me? )) > It has been working at 10 MHz for over a year. > It's simply too complex. The best part about it is the buffer handling (you > can separate the transmit header from the body), but the Mostek/AMD "Lance" > has all of the needed functionality in the buffer handling area (including > command and data chaining) but is a lot simpler to use. (The "Lance" was > clearly built to do Ethernet. Certainly, it's too complex. Ironically, though, most of the bugs in the early revs of the silicon were not due to the configurable net parameters, but in the buffer handling. The LANCE is certainly cleaner and simpler, but the reality of the situation is that useable silicon was available for the Intel chip more than 1 year before the LANCE. > > Surprisingly, the one configurable parameter that is needed desperately is > missing. The "Lance" lets you select Big-Endian vs Little-Endian byte order > within a 16-bit word ("byte swap" or not on transmit/receive data, without > affecting command descriptors), a feature that the 82586 sorely needs when > handling DoD/IP or XNS (both of which are "Big-Endian"). The 82586 is > "optimized for operation with the iAPX 186 bus [80186] but can be used > with other general purpose processors." [p. 2-2] It's gonna be REAL fun > to use with a 68000... ;-} > > Someone PLEASE correct me if I am wrong on this point, as it is critical > to avoid the overhead of swapping bytes in software before/after you > transmit/receive. Although I looked through the User's Guide and the Data > Sheet carefully, I found no mention of byte order, except one very clear > picture of the address bytes which shows it to be "Little-Endian" (the first > byte sent is bits 7-0, the second byte is 15-8, etc.). It may very well be > that the only reasonable way to use the 82586 (even with a 80186) is to > reverse the high and low bytes in the wiring of the board, though this will > totally confuse the programming of the control and descriptor blocks (which > contain addresses in them). Still, it is perhaps better to do that than to > flip all the data. > It is really not that hard to use with a 68000. Since the 82586 has a multiplexed address/data bus, you have to have address and data latches anyway to demultiplex the bus. (also true of the LANCE) The data latches can be used to always swap the bytes. It does confuse the control block programming, but this doesn't turn out to be so terrible. The flag bits are no problem, since they can be defined as C bit fields, but the addresses do have to be swapped. Even if the the byte order within a word could be programmed, the software would still have to take special precautions with the 24 bit buffer addresses, since the highest byte in the address is at the highest address. In any case, it is a pain, but one that is very easy to localize and be done with. You are certainly right that the data should be swapped in hardware. All of your points are correct, but I believe you err in your fervor. My experience with the 82586 has shown that its problems are not insurmountable, nor do they cause negative impact on system performance. And, I emphasize, despite its complexity, it did beat the LANCE to market by more than a year. (Yes, the SEEQ chip was there even sooner, but it requires a LOT of external hardware if you want to receive back-to-back packets). I suspect that making the parameters software-settable was no harder that hardwiring them into the mocrocode. And, if Multibus II systems end up using the part for talking to the Multibus II serial bus, it may turn out to have been a good move by Intel. Cheers, Mitch Bradley
schoff@cadtroy.UUCP (Martin Lee Schoffstall) (10/15/84)
> The 82586 processor handles mainly the media access protocols (I think). > Since the Sytek network is CSMA/CD, all they have to do is put different > serial encoder on and they have a broadband network. The reason they can > use CSMA/CD on a rather large CATV plant is the data rate on the broadband > channel is only 128kbps (assuming it is the same as the Sytek Localnet 20 > product line). > They call the product Localnet/PC. The only problem is that they advertise a data-rate of 2Mbits. It is possible however that each channel is running at 128kbits and some concatenatin of channels gives them an aggregate of 2Mbits. In fact since they seem to want virtual disks across this network, it would be a real loser if the transfer rate was limited by one channel@128kbits. marty
phil@amd.UUCP (Phil Ngai) (10/15/84)
> +--------------- > | In the October issue of BYTE IBM has an advertisement and specification > | of this new networking capability. They say they are using the Intel > | 82586 processor. I thought that this was an ethernet processor? > +--------------- > > It is. Intel calls it the 82586 Local Area Network Coprocessor. Not ethernet processor. It can be used to implement an ethernet interface, but it can also do other things, like run lower speed (lower cost) local area networks. My personal opinion is that the versatility of the 82586 is a good thing because it allows you to do more with the same silicon while not doing any particular application less well, thanks to its programability. And it interfaces to the 80186 VERY easily. -- Phil Ngai (408) 982-6554 UUCPnet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amd!phil ARPAnet: amd!phil@decwrl.ARPA