The birth and rise of Ethernet: A history | Hacker News Reader

The birth and rise of Ethernet: A history

insights.hpe.com

75 pointsCrankyBear24 comments

The article doesn't explicitly name Ron Crane, but he was instrumental to the history of Ethernet, especially the practice engineering aspects. He passed away last week, and the world has lost a great engineer.

https://duckduckgo.com/?q=ron+crane+ethernet&t=ipad&ia=video...

Triggered scary flashbacks to chasing down network problems with a big TDR (time domain reflectometer--basically a way of checking connectivity by virtually walking down the wire) on MIT's CHAOSnet thick yellow coax, climbing around ceilings and under raised floors in building 38 (EECS) late at night, around 1979-80.

(The coax came from Tech Square buildings (MIT-LCS/AI), and was used to connect up the DECsystem-20 and (MIT) Lisp machines we had in building 38.)

BTW CHAOSnet used a different CSMA-based protocol than PARC Ethernet (which used PUP, also later superseded).

Ron Crane and Dave Boggs visit the Xerox Alto Restoration project and show some early ethernet gear and talk a bit about the technology: https://youtu.be/XhIohWr10kU

Hehe in part 16 they telnet google.com. Time Travel.

Nothing makes me feel so old as reading something and thinking, "I was there for this."

Thicknet, AUI and vampire taps. I don't miss that.

I recall having a coaxial network between some sun workstations that gave me a pretty good shock whenever I touched the exposed metal bits. WiFi is much better in that regard.

Experienced something similar at a LAN party, and as best i understood the reason for this was poor grounding on one of the computers on the network.

Less of a problem once the coax was retired as there is no direct electrical connection between the computers.

I don't think of myself as being _that_ old (will be turning 35 soon) but my first LAN party was done with 10BASE2 and I remember working a summer/intern job at a factory that used a token ring network...

So either I'm in denial or you're being too hard on yourself!

[ though all bets are off if you were at PARC when they were lighting it up, in that case... you definitely are old :) ]

I'm just a bit older than you. In the 90s I got my first tech job while still in high school. The company I was working for was in the middle of moving to a new building that would have a 10Base-T network, but the current building had 10Base-2 coax.

My first week was, after getting in from school, going around to people's offices and swapping whatever network card was in their machine for a 3C509 combo card that had base-T, base-2 and another port that I think was AUI if I remember right. That way the transition would be easier when the new office was ready.

At the end we had a bunch left over and my boss let me keep them. That was my first NIC. I think I still have it somewhere. I gave some away to my friends so we could have LAN parties. :)

You are correct that the third port was AUI. I don't remember the exact details, but early in high school I bought a box of random computer hardware at auction for $20, and it had probably a dozen 3C509s in it. Add in a 10mbit hub that the school threw in a dumpster... Now all my friends now had Ethernet cards and we could start having LAN parties!

I remember reading all these in catalogs. Funnily enough, whenever I read a 10BASE2 I feel the same magical emotion coming up; while I'm jaded by a a 64GB microsd or a NVMe SSD

My emotion is rather anger of having to track down network connection issues by unplugging computers one by one, until I finally managed to find which connector wasn't propagating the signal properly.

I have done this multiple times and was really happy when we finally got RJ45 cables.

I am few years older and i similarly recall the first LAN party or two i attended used coax. I also once rigged an ad-hoc party at a friends place using a hub with a hookup for coax. To this day i am amazed it worked without any fuses blown or similar.

Never had to deal with token ring though, just TCP/IP and IPX/SPX.

I had bitter flame wars on CompuServe about whether I should sell ARCnet to my customers. And I still own the hardware for cutting cable and fastening those stupid connectors.

So not quite in the PARC realm, but not too far from it.

from http://ethernethistory.typepad.com/papers/EthernetPaper.pdf (1975):

> Recognizing the costliness and dangers of promising "error-free" communication, we refrain from guaranteeing reliable delivery of any single packet to get both economy of transmission and high reliability averaged over many packets [Metcalfe, 1973b]. Removing the responsibility for reliable communication from the packet transport mechanism allows us to tailor reliability to the application and to place error recovery where it will do the most good. This policy becomes more important as Ethernets are interconnected in a hierarchy of networks through which packets must travel farther and suffer greater risks.

The Ethernet CRC works at the right timescales / data rates and does not depend on information or assumptions about above layers. It works mostly OK at quickly knocking out packets that got grossly mangled in transit -- to avoid bothering hosts with corrupted packets and to avoid transmitting them further -- but that's it. There's no retransmissions, no acknowledgement/negative-acknowledgement mechanisms, no negotiating, no dependence on address schemes. Implementing the physical layer's error correction/detection mechanisms in a minimal way appropriate to that specific physical medium was a master stroke of design. This sort of end-to-end aware design gave higher layers freedom to do what they wish (in terms of latency or reliability) but also let the Ethernet frame standard remain useful for networks far beyond 10Base5.

Some Ethernet switches are in a great hurry and don't want to wait to fully receive (and CRC-check) an incoming frame before starting to output it. They start outputting a frame as soon as they know where to output it: when they've finished hearing the full destination MAC address. This is kinda iffy, because the switch hasn't seen the end of the frame, so it can't know the CRC value of the incoming frame! How are they to cope with a corrupt inbound packet, if they've already started transmitting it out? There's no way to undo transmitting it, so the switch takes the next best approach -- spitefully ruining the outgoing frame, by setting its CRC field to something intentionally incorrect. It'll never checksum right, and will be discarded at the first device capable of doing so.

Your description of cut-through switching isn't quite correct.

If the packet is corrupted, there is no need for the switch to intentionally break the CRC, since the only way it knew the packet was corrupted in the first place was the broken CRC. Modifying the existing, broken CRC, would create a small chance of accidentally "fixing" the corrupted packet, whereas just continuing to forward it would ensure that a later (store-and-forward) switch, or the end-host would detect the broken CRC and discard the packet.

Thinnet was definitely a revolutionary advancement. We wired my apartment building on University Ave for thinnet in 1989 (when my apartment was the first POP for the ISP TLG, though the term "ISP" hadn't yet been coined).

After the 1989 Loma Prieta earthquake ruined the driveway between the two apartment buildings, we asked the manager if we could run thinnet under the new driveway they were pouring. He shrugged and said, "sure" though he had no idea what it meant; the cable simply looked harmless. A few years ago I walked up and looked and the cable is still there emerging from the ground :-).

(How times change: people actually sought apartments in that building because it had fast internet built in, yet when they would ask the manager about it he had no idea what they were talking about)

There was a brief period of time in the mid-90s before 100 Mbps ethernet where FDDI made an appearance:

https://en.m.wikipedia.org/wiki/Fiber_Distributed_Data_Inter...

I'm astonished this happened without government funding :-)

Back then blue sky was seen as an investment, not an expense. These days it seems like anything that do not produce a positive stock value tick in the next quarter is 86ed asap.

Amazon, Tesla, SpaceX, etc. suggest otherwise.

Reply on news.ycombinator.com