| Author |
Message |
J. Clarke
Guest
|
 Posted:
Thu Mar 10, 2005 3:25 am Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
James Knott wrote:
| Quote: | Andy Ball wrote:
I like BNC for low power connections, N for heftier stuff.
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
<http://www.amphenolrf.com/products/bnc.asp>. 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.
--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net) |
|
| Back to top |
|
 |
Rich Seifert
Guest
|
| Posted:
Thu Mar 10, 2005 6:54 am Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
In article <L2IXd.4422$oO4.450@newsread3.news.pas.earthlink.net>,
Andy Ball <null@not.valid> wrote:
| Quote: | Hello Rich,
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...
|
There was a minimum spacing requirement (transceiver-to-transceiver) of
0.5 m, but that was it. There was no preferred cable length.
--
Rich Seifert Networks and Communications Consulting
21885 Bear Creek Way
(408) 395-5700 Los Gatos, CA 95033
(408) 228-0803 FAX
Send replies to: usenet at richseifert dot com |
|
| Back to top |
|
|
Rich Seifert
Guest
|
| Posted:
Thu Mar 10, 2005 7:23 am Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
In article <lImdnZFFMrNQk7LfRVn-vQ@rogers.com>,
James Knott <james.knott@rogers.com> wrote:
| Quote: | Rich Seifert wrote:
Incidentally, I have every issue of Byte on the shelves behind me.
You will find an article I wrote in the January 1990 edition,
chronicling the 10th anniversary of the Ethernet ("Blue Book")
Specification. A group of the original designers got together in my home
for a reunion party, which resulted in the article.
Actually, it's the Jan 1991 issue, page 315.
"Ethernet: Ten Years After"
Perhaps you could post the text or a link to it here. I'm sure others would
find it interesting.
|
Sure, why not?
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
Send replies to: usenet at richseifert dot com |
|
| Back to top |
|
|
Al Dykes
Guest
|
| Posted:
Thu Mar 10, 2005 7:31 am Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
In article <usenet-3C8997.18232009032005@news.isp.giganews.com>,
Rich Seifert <usenet@richseifert.com.invalid> wrote:
| Quote: | In article <lImdnZFFMrNQk7LfRVn-vQ@rogers.com>,
James Knott <james.knott@rogers.com> wrote:
Rich Seifert wrote:
Incidentally, I have every issue of Byte on the shelves behind me.
You will find an article I wrote in the January 1990 edition,
chronicling the 10th anniversary of the Ethernet ("Blue Book")
Specification. A group of the original designers got together in my home
for a reunion party, which resulted in the article.
Actually, it's the Jan 1991 issue, page 315.
"Ethernet: Ten Years After"
Perhaps you could post the text or a link to it here. I'm sure others would
find it interesting.
Sure, why not?
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!
|
And ATM ("asyn transfer mode") was going to be better as desktop LAN
infrastructure than any of these, according to my boss at the time.
| Quote: | ----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
Send replies to: usenet at richseifert dot com
|
--
a d y k e s @ p a n i x . c o m
Don't blame me. I voted for Gore. |
|
| Back to top |
|
|
James Knott
Guest
|
| Posted:
Thu Mar 10, 2005 7:37 am Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
Rich Seifert wrote:
| Quote: | 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.
|
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. |
|
| Back to top |
|
|
JD
Guest
|
| Posted:
Thu Mar 10, 2005 8:04 am Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
It takes a brave man to admit he was behind this device of torture.
And yes, I cursed.
Jay Drew
Rich Seifert wrote:
<<<SNIP>>>>
| Quote: | 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
Send replies to: usenet at richseifert dot com |
|
|
| Back to top |
|
|
Hansang Bae
Guest
|
| Posted:
Thu Mar 10, 2005 8:04 am Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
James Knott wrote:
[snip]
| Quote: | 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)
|
Oh no...here we go again! :)
--
hsb
"Somehow I imagined this experience would be more rewarding" Calvin
**************************ROT13 MY ADDRESS*************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
******************************************************************** |
|
| Back to top |
|
|
Robert Redelmeier
Guest
|
| Posted:
Thu Mar 10, 2005 6:31 pm Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
Rich Seifert <usenet@richseifert.com.invalid> wrote:
| Quote: | 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).
|
Perhaps worried about copyright infringement?
| Quote: | As you read it (*IF* you read it, that is) remember that
|
A wonderful read! Thanks for posting it.
Imagine -- random network addresses. Finally a good use
for those 128 bit IPv6 addresses. 64 bits route, 64 bits rand.
I doubt it will happen given governmental influence.
-- Robert |
|
| Back to top |
|
|
James Knott
Guest
|
| Posted:
Thu Mar 10, 2005 7:05 pm Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
JD wrote:
| Quote: | It takes a brave man to admit he was behind this device of torture.
And yes, I cursed.
Jay Drew
Rich Seifert wrote:
SNIP
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."
|
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... |
|
| Back to top |
|
|
Rich Seifert
Guest
|
| Posted:
Thu Mar 10, 2005 8:50 pm Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
In article <7%XXd.5824$WK2.743@newssvr30.news.prodigy.com>,
Robert Redelmeier <redelm@ev1.net.invalid> wrote:
| Quote: |
Imagine -- random network addresses.
|
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
Send replies to: usenet at richseifert dot com |
|
| Back to top |
|
|
Al Dykes
Guest
|
| Posted:
Thu Mar 10, 2005 9:43 pm Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
In article <vuSdnZLUBqSxya3fRVn-rQ@rogers.com>,
James Knott <james.knott@rogers.com> wrote:
| Quote: | JD wrote:
It takes a brave man to admit he was behind this device of torture.
And yes, I cursed.
Jay Drew
Rich Seifert wrote:
SNIP
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."
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...
|
The little latch created a market for an outfit that patented and made
replacement clips that worked fine. I can't recall the brand.
I found that a tie-wrap of the right size looped thru one side of the
clip worked fine. I never had a problem.
--
a d y k e s @ p a n i x . c o m
Don't blame me. I voted for Gore. |
|
| Back to top |
|
|
Al Dykes
Guest
|
| Posted:
Thu Mar 10, 2005 9:45 pm Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
In article <7%XXd.5824$WK2.743@newssvr30.news.prodigy.com>,
Robert Redelmeier <redelm@ev1.net.invalid> wrote:
| Quote: | Rich Seifert <usenet@richseifert.com.invalid> wrote:
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).
Perhaps worried about copyright infringement?
As you read it (*IF* you read it, that is) remember that
A wonderful read! Thanks for posting it.
Imagine -- random network addresses. Finally a good use
for those 128 bit IPv6 addresses. 64 bits route, 64 bits rand.
I doubt it will happen given governmental influence.
-- Robert
|
Same here. Thanks for all the bits.
--
a d y k e s @ p a n i x . c o m
Don't blame me. I voted for Gore. |
|
| Back to top |
|
|
J. Clarke
Guest
|
| Posted:
Fri Mar 11, 2005 12:18 am Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
Al Dykes wrote:
| Quote: | In article <vuSdnZLUBqSxya3fRVn-rQ@rogers.com>,
James Knott <james.knott@rogers.com> wrote:
JD wrote:
It takes a brave man to admit he was behind this device of torture.
And yes, I cursed.
Jay Drew
Rich Seifert wrote:
SNIP
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."
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...
The little latch created a market for an outfit that patented and made
replacement clips that worked fine. I can't recall the brand.
I found that a tie-wrap of the right size looped thru one side of the
clip worked fine. I never had a problem.
|
Could be worse. At least when the latch busted it didn't destroy the
connector.
--
--John
to email, dial "usenet" and validate
(was jclarke at eye bee em dot net) |
|
| Back to top |
|
|
glen herrmannsfeldt
Guest
|
| Posted:
Fri Mar 11, 2005 8:03 am Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
Al Dykes wrote:
(snip)
| Quote: | The little latch created a market for an outfit that patented and made
replacement clips that worked fine. I can't recall the brand.
I found that a tie-wrap of the right size looped thru one side of the
clip worked fine. I never had a problem.
|
People I used to know, for transceivers where the cable
came out parallel to the coax would put a wire tie around
both cables. I usually didn't because I would want to change
them too often, and it was too much work to get the ties on
and off.
-- glen |
|
| Back to top |
|
|
Hansang Bae
Guest
|
| Posted:
Fri Mar 11, 2005 8:03 am Post subject:
Re: Does anybody have 10base5, 1base5, starlan1, or 10broad3 |
|
|
Rich Seifert wrote:
| Quote: | 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.
[snip] |
But when you do run into a problem, it can be a bear to troubleshoot.
This happened back in 1990 or so when (Centris, was that the name of
Apple boxes???) boxes had issues with duplicate addresses. The only
way to fix it was to zap the p-ram. that was a pain in the ass.
--
hsb
"Somehow I imagined this experience would be more rewarding" Calvin
**************************ROT13 MY ADDRESS*************************
Due to the volume of email that I receive, I may not not be able to
reply to emails sent to my account. Please post a followup instead.
******************************************************************** |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in