I did it once. We bought some Suns that we were told would have built in 10base2, but didn't. We ordered some transceivers, but I wanted to get the machines running. I put two vampire taps on some RG8 (probably RG/213, actually) soldered BNC connectors onto each end, and had it running for some weeks. The only problem was that once one of the BNC connectors shorted out (they were panel mount connectors). The clamp was tight enough not to wiggle too much, but I probably wouldn't put it in the wiring tray.
OK, the more I learn, the more I learn I don't know.
I'm interested. Unless the tranceiver is 100baseTX 100baseT4, in which case I am VERY interested.
A web search...if I learned correctly, there is a DB40 AUI connector for 100 megabit ethernet, from which one can connect a 100baseT4 tranceiver or a 100baseF tranceiver (and maybe others), but it never caught on and interface cards nearly all have RJ45 ports for 100baseTX only.
So it would be nice to have as a display item, but unless I can get network interface cards with drivers (I think I saw a reference to a list of cards supported by some linux driver including some 100baseT4 cards) and maybe a hub/switch, it is not something I could set up and have running live.
As I understand it, 100baseT4 is 3 pairs transmit, 1 pair control/collision/receive I can see that meaning either a hub is a requirement or any cable can connect two DTE devices together without a hub and a crossover is not required, but I could not find anything on the web to explain how it works (probably a shortcoming in what to look for on the web, I'm sure its there somewhere)
The first ethernet network I worked on (or even saw), was a DECNET, connecting several VAX 11/780 computers and used vampire taps. However that's not my first experience with networks. That would be on a system built by Collins (part of Rockwell). They had a network, that instead of using packets, used time slots (time division multiplexing). When a device (computer, tape drive, disk etc.) wanted to send data, it would be assigned a time slot on the ring. The destination would then listen to that time slot. While the time slots could have been assigned dynamically, in the systems I worked on, they were permanently assigned. IIRC, the Collns
8500B had a 2 Mb/s ring over RG-58 cable, while the 8500C ran 8 Mb over triaxial cable. There were also adapters to convert between the two speeds. The ring had relay boxes, for connecting the various devices and a loop sync box, to retime the signal. As I recall, this technology was developed in the mid '60s. I was working on it in the late '70s, a few years before ethernet was created.
I worked for BigBank in NYC in the late 70's and the CTO was really big on pre-standards channel-oriented broadband LAN for buildings and ISO (meaning mostly X.25) WAN. The cable plant for the BB was identical to any CATV system except we didn't have telephone poles or manholes. Our engineers joked that if/when the got downsized they could all go home and get jobs with the local cable TV company and have a shorter commute.
Many of the engineering issues for our BB and an outdoor CATV system were similar because we were in a very high EMI environment (a couple thousand feet LOS from the Empire State bldg) and interference was always leaking into all sorts of stuff. Years later I could hear AM radio on my PC before streaming was invented.
The CTO later went on record as "ethernat can't work" and BigBank became a huge TokenRing operation. I had to jump thru hoops to get ethernet in for my DEC datacenter. We spent MILLIONS on OSI stuff and it was a PITA to get it connected to all the types of DEC gear I had. OTOH, I had thousands of users, worldwide, by 1982. TCP/IP, What's that ?
That Collins 8500C system that I worked on, was part of the Air Canada reservation system. That system ran on a Univac computer, and the Collins network was the communications processor for it. As I mentioned in the other note, devices such as tape drives and disks were connected to this network. There were also about 2 dozen PDP-11s connected, each with 3 or 4 serial I/O cards, each card containing a Motorola 6800 CPU and 8 UARTs, which were then connected to modems, to talk to terminals around the world.
I haven't got anything that requires N connectors, but I like using BNC. If any gear comes with an SO-239 connector, I use an adapter to convert to BNC.
Incidentally, one thing that really gets me, is all the names for a BNC connector. It is not "British Naval Connector" or that other common one with a couple of people's names. According to what I read in Ham Radio Magazine, several years ago, a guy from Amphenol (IIRC) said it's derived from:
B - bayonet lock N - N type (you can actually plug a male BNC into a female N, though the lock won't work C - compact (version of N series)
Seems that Amphenol disagrees with you . Unless the guy who wrote the article was named Neill or Concelman I'll take the official Amphenol story over that that appeared in a magazine.
RHS> As a ham myself (KE1B), I would have liked PL-259s, > since I could have gotten all I wanted as vendor > samples from Ethernet cable manufacturers!
JAK> Another one here, VE3ZU.
I'm in good company then :-)
I've seen coaxial Ethernet used in places where EMC was an issue. I've thought about using it in the shack for this reason (well, that and I'm likely to have reels of it sculling about the place anyway ;-)
I like BNC for low power connections, N for heftier stuff.
Below find the original article *as I submitted it to the magazine*; i.e., before the editor's got their hands on it. Note that even then, I was using titles and/or lyrics from popular songs for section headings, a practice I continued through my later books (a practice that the editors of BYTE Magazine disagreed with). Even the original title of the article was "Reflections of ... the Way Life Used to Be" (a line from an old Supremes song)
As you read it (*IF* you read it, that is) remember that it was written in October 1990, a time when 10BASE-T was quite new, FDDI was emerging as the next-generation LAN, and Fast/Gigabit Ethernet did not yet exist.
Enjoy!
----Begin Article----
Reflections of...the Way Life Used to Be
One thing that differentiates humans from lower beings is their ability to defer instant gratification for long-term pleasure (some humans, anyway). One of the more difficult tasks in this regard is to hold onto a fine wine long enough to allow it to reach its peak. You see it every time you open the wine cabinet, reminding you of its wondrous pleasures to delight the palate, but still you let it lie, to reap an even greater reward later on. If you are really patient, the flavors that finally roll across your tongue are further enhanced by the remembrance of all those years of anticipation.
I purchased a magnum of Cabernet Sauvignon from Heitz Cellars on September 30, 1980, the day we completed and "signed-off" the DEC-Intel-Xerox Ethernet Specification, Version 1.0. I planned to enjoy it with the Ethernet team on the tenth anniversary of that day. We recently reunited to enjoy that wine and to reflect on the evolution of LANs over the past ten years.
Imagine There's no Network, I Wonder if you Can?
While it's never easy to expand the horizons of one's business, at least today there is an established market for LANs. You can do the market research, listen to network users, find their needs, and determine the niches where new ideas and products can flourish.
In 1980, none of this was possible. Imagine a world without networks: no Novell/3Com/TOPS, no clients, no servers. No Token Ring, Ethernet, or LocalTalk. No transceivers, wiring hubs, bridges or routers. No TCP/IP, no OSI. No PCs! Networks involved either proprietary point-to-point connections or leased lines from the telephone company, and 300 baud modems were standard. This was the environment in which the industry, and the DEC-Intel-Xerox partnership was in when we began our effort. We had to go where no LAN had gone before.
A blank sheet of paper is a scary proposition. Most engineers and product marketers rarely get to work with one. You are usually designing a product which is second- or third-generation, an incremental improvement on an existing concept, a logical extension of existing ideas.
Working on an established field of play can have its drawbacks too, especially for established players. As Enzo Torresi (President of NetFrame Systems) said, "The only reason God could create the world in six days was because He didn't have to worry about the installed base." Backwards compatibility is the bane of the systems designer. You can't (or shouldn't!) ship new products which don't interoperate with the products you shipped last year. It's a great way to lose customers.
We had no such problems with Ethernet in 1980. It was more than a clean sheet of paper. It was an empty book.
Don't Know Much About History, Don't Know Much Technology...
In the early-mid 1970s, Robert Metcalfe and his group at Xerox's Palo Alto Research Center (PARC) invented and implemented an early Ethernet system. This became widely used within Xerox, becoming a key part of their Alto computer system (which was never commercialized). The Alto was the basis for the later, commercial Xerox Star, and in many ways, the Apple Macintosh.
During 1979, Xerox, together with Digital Equipment Corporation and Intel, worked to transform the core Ethernet work done at PARC into a network standard, implementable in silicon and suitable for volume use and manufacture by a wide variety of companies.
Employees from each of the three companies worked together from 1979 through to the publication of the Version 1.0 specification in September, 1980. (A Version 2.0 was published in November, 1982. The major change was the inclusion of standard Network Management capabilities.)
While the original technology was functional, it was not a complete design. The DEC-Intel-Xerox team solved the problems of building large networks, algorithm stability, electrical and system performance, installability, reliability, cost, etc. The resulting design used the same basic principles as Metcalfe's prototype (it was still a CSMA/CD bus), but bore few other similarities. The changes included:
Electrical signaling Cable types, connectors, etc. Packet formats CSMA/CD and backoff algorithm, CRC calculation System timing, Network Management primitives, etc.
The result was a well-specified (anyone could build a compatible product from the specifications) system that could support all those applications we thought about that didn't yet exist.
Too much? Too Little? Too Late?
When the Ethernet technology was first exposed to the market, we drew lots of criticism:
--It's overkill (who needs 10 Mb/s?)
--It costs too much (controller boards were $1000-4000, without software, transceivers, etc.),
--I don't understand it; it's too complicated.
Of course, all of this was true. In 1980-82. No one needed 10 Mb/s. There was hardly a computer around that could keep up with that data rate, much less do anything useful with the information at that speed. A common technology in use at the time was Corvus Systems' OmniNet, a 1 Mb/s twisted-pair bus, used primarily for disk sharing among Apple II computers.
We resisted the temptation to develop what the market needed at the time. There was a vision of distributed databases, interoperability, and multi-vendor networks that exceeded the capabilities of simple technology. It was more important to put an infrastructure in place that could support the development of a wide variety of applications, and have a long enough product life to allow those applications to grow without having to tear out the underpinnings every few years. It's like building a two-lane road to a new frontier; It will get you there now, but will be obsolete by the time the frontier is developed. Better to build a superhighway, and let it be empty for a while. There will be people to use it soon enough. (No surprise that two-thirds of the Ethernet triumvirate were in California!)
I Can See Clearly Now, the Rain is Gone.
The original Ether-thinking was conscious, long-term planning. It wasn't intended to be some nifty new technology that would give a competitive advantage to the developers. That's why we opened the design and architecture from the beginning. Any disadvantage incurred by allowing competition to flourish was offset by the increase in the size of the total market. Networks are only truly useful when everyone does it. Even a small piece of the pie is adequate, if the pie is huge.
We used a 20 year product life as our model, expecting that installations and quantities would ramp up over the first 5-10 years, and then taper off as middle age set in, and some new technology emerged. This was before there was even a complete system design; no silicon, no independent networking companies, no applications, nothing.
It's interesting that we aren't hearing the same complaints today about FDDI (other than cost, of course!). The reason is that we have learned the Ethernet lesson of letting the market and applications develop to use the technology as it matures. FDDI-based systems today do not take full advantage of the technology; neither the available silicon, the protocols we commonly use (today), nor the attached systems can truly exploit the full capability of the channel. But the FDDI community is thinking and planning for the future. They learned from the Ethernet experience how fast one can go from overkill to underpowered.
We saw Ethernet as the "UART of the 90s". In 1980, no reasonable manufacturer built a computer without an RS-232 port. (UART stands for Universal Asynchronous Receiver/Transmitter. It is the key component of a serial port.) Even if you didn't have an immediate use for it, you put one in anyway, because it gave your users flexibility. Our vision was that in 1990, computer manufacturers would put networking into every machine, for the same reasons.
Look what they've done to my song, Ma!
Virtually all of that vision came true. Look at Sun workstations, DEC VAXen, and Apple Macintoshes. Networking is an integral part of the product. Every Sun comes with an Ethernet port; every Mac with a LocalTalk connection. The only way to connect terminals to (the larger) VAXen is through Ethernet, Terminal Servers, and LAT (Local Area Transport).
The business truly evolved to exploit the technology that was offered. In fact, many of the successful networking companies today were started by those very people who worked on the original Ethernet technology. Founders and key personnel at 3Com, Sun Microsystems, Xyplex, Metaphor, Industrial Networking, Apple, Racal-Interlan, Wellfleet Communications, Ultra Technologies, Ascent Communications and Networks & Communications all came from the original Ethernet specification work team.
The LAN business has exploded during the 1980s, in parallel with PCs, to totally transform information technology compared with 1980. LAN hardware, LAN VARs, third-party installers and support, thousands of software applications; none of this could have existed without the core technology and standards.
What may be more interesting are all of the things that we didn't foresee that have affected our business. "No one predicted the emergence of twisted pair as the medium of choice," says Bob Printis, Manager of Systems Architecture at Xerox's Palo Alto Research Center, and one of the few team members still with their original company. The original Ethernet was coaxial-cable based. This invariably required the installation of new cable to implement an Ethernet LAN.
As the technology became a commodity (LANs were no longer exciting in and of themselves), people became more concerned with "mundane issues" such as wiring up one's building. It turns out that issues like these have become much more important than the communications system in use on that wire. The reasons twisted pair wiring is popular have nothing to do with data rates, or electrical characteristics. They have to do with ease of installation, reconfiguration, and cable management. During the Ethernet design, we never realized the extent to which these issues would overshadow electrical performance. Twisted pair has worse noise performance, higher bit error rates, and can run at LAN data rates only over much shorter lengths than coaxial cable or fiber. But users are willing to live with these restrictions in exchange for the administrative advantages it offers.
As in many other facets of life, people are willing to give up a lot for convenience.
Don't you Care? Don't Yoo-ou Care??
Take a look in an old issue of this magazine (or any publication covering the networking industry). Go back to 1980-84. You will find articles touting the superiority of baseband to broadband. Or of broadband to baseband. Or of Token Ring/Ethernet/Token Bus/Slotted Rings, etc. to each other. You don't see these anymore. The network wars are over. And everybody has won. (Well, almost everybody.)
When networking consisted solely of technology, technology was the subject of controversy. The fundamental building blocks of our business were just being cast, and everyone argued over the shape and color of the bricks. But today the technology is pass. There is little excitement over a new networking chip, another terminal server, a new bridge or router.
There used to be arguments, in the standards bodies and trade press, over such minutiae as preamble bits, frame formats, type and length fields, checksum algorithms, and address lengths. While all of these things were ultimately decided, it turns out that it really didn't matter what the decisions were! The important thing today is that they were decided, and we could get on with the business of networking. The reason these were not really important is because networking is not technology. Today, hardly anyone cares about the technology (as long as it works). There are only three things users really care about today:
(1) What applications can I run on my network? (What can it do for me?) (2) How should I wire my building? (You only get one chance to do it right.) (3) How do I manage the network effectively?
Users are not concerned with the shape of the connector, the color of the cable, or the formats of the bits on the wire. It's not Token Ring vs. Ethernet, it's applications which run on Token Ring vs. applications which run on Ethernet. To the extent that applications, wiring systems, and network management are technology-independent, the underlying network characteristics become invisible and unimportant. The only vestige of their presence is performance. But there is rarely a perceptible performance difference once all the layers of software, server bottlenecks, and disk latencies are inserted between the user and the wire.
It don't come easy, you know it don't come easy!
It is nice to think that smart people can look at a problem, figure out the solution, write it down, and tell everyone about it. It's also nice to win the lottery, but the probabilities of the two events are roughly equal.
What was published as the Ethernet "Blue Book" in 1980 was just the results of all the discussions, tests, mistakes, and negotiations that went on for more than a year before release. There were really more variations than one can imagine. At various stages in its development, Ethernet had:
-- Preambles from 1 to 64 bits long
-- A variety of different Collision Detect methods
-- 16 bit CRC
-- HDLC framing (flag characters and bit stuffing)
-- Address lengths from 32 through 64 bits
This last item is especially interesting. The (ultimately agreed-to) Ethernet scheme of 48 bit universal addressing was accepted and adopted by the IEEE 802 and FDDI network standards. But with only (!) 48 bits, you need some form of address administration to ensure that no two stations have the same address. This is done by allocating blocks of addresses to vendors, from which they are individually responsible for assigning unique addresses to their products.
But with a 64 bit address space, a station could select an address at random, and the probability that two stations on the same network had the same address would be insignificant! We went through the mathematical analysis 10 years ago, and proved it (at least to ourselves). "But no one would have believed us," said Printis. "We would have had to fight an endless battle on that one." This became especially painful for Printis, who initially inherited the responsibility of assigning the vendor address blocks correctly.
....and if we had the chance to do it all again, tell me, would we?
We surely would, but not exactly the same way. It's such a luxury to see with hindsight, but let's indulge ourselves. If the original Etherneters could change anything, what would they change?
Dave Redell, originally Principal Scientist with Xerox Business Systems, and now a Member of the Research Staff at Digital Equipment Corporation's Palo Alto Systems Research Laboratory would have set the maximum packet size higher than the current 1500 bytes. "There was nothing magic about that number," said Dave. "It was a compromise. The main concern at the time was the cost of memory." During the specification discussions, the packet size limit varied from around 600 bytes to as much as 10 Kilobytes. Longer packets make for more efficient channel utilization, but also increase the probability of both an error in the packet, and that there may be a collision on the next packet. But the overriding concern at the time was that simple (read "cheap") controllers would allocate a fixed, maximum size buffer for every received packet. With 1K and 4K RAMs being the norm (1979, remember?), this was a major concern. So, we compromised. 1500 bytes allows for 1K bytes of user data, plus any reasonable protocol overhead. "If it were longer, large file transfers would be faster, and we might have avoided some of the Token Ring-to-Ethernet bridging hassles," laments Redell.
Bob Printis would have included a Length field and avoided the Ethernet vs. IEEE 802.3 wars. (The only significant difference between the two is the IEEE's use of the length field vs. Ethernet's use of a Type field.) "Of course, if we had done that, they [the IEEE] would have found another way to make it incompatible," said Bob. "At least we found a workaround for the problem." It is possible to make the two at least coexist by assigning all type field values to be numerically greater than the maximum length of 1500 bytes.
This author would have saved every Ethernet user a lot of grief by not specifying that [expletive deleted] slide-latch connector (used on the cable between the station and the transceiver). "We really had good intentions. I was fed up with RS-232 connectors that fell off because the tiny screwdriver necessary to tighten them down was never handy. I just never realized that the slide latch was so flimsy and unreliable until it was too late. Ethernet installers around the world must curse me every day."
----End Article---- (C) 1990 Rich Seifert and Networks & Communications Consulting. All rights reserved.
-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX
RHS> The forced spacing was to prevent lumped capacitive > loads on the system, which could cause unacceptable > signal reflections.
I understand that you wrote this about original 'thick' Ethernet, but I'm wondering if there are preferred lengths for 10base2 cables. Would certain lengths minimise the effect of any reflections from the BNC connectors? I don't remember 10base2 being especially fussy, but an ounce of prevention...
Yes, I did read it, both this morning and 14 years ago. As I mentioned in another note, by the time ethernet came out, I had already been working on a computer network for a few years, though it was quite different from ethernet, though in some ways similar to token ring.
No need to "imagine" it. This is precisely what happens within AppleTalk, both at the Network layer (DDP), and the LocalTalk Data Link. Stations choose their station identifier at random (at least the first time), then ask if anyone else is using the address (repeated times). If no one responds, the station uses the randomly-selected identifier, and stores it locally. If the station is reset, or powered down/up, it will first try the address it used last time, again checking to see if anyone else started using it while the station was dormant.
In general, stations will use the same address over long periods of time, particularly in unchanging network configurations. If stations are often added, moved, etc., the addresses will vary considerably over time. However, at any given time, each active station will have a unique address.
-- Rich Seifert Networks and Communications Consulting 21885 Bear Creek Way (408) 395-5700 Los Gatos, CA 95033 (408) 228-0803 FAX
I didn't have much experience with those latches on ethernet, but some terminals I used to service used them. They were certainly a royal pain in the...
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.