Few technologies are as pervasive in our lives as Ethernet.
Doug Boom and Kevin Bross, engineers in our Intel Ethernet group, are working on foundational technology that keeps the world spinning, and open source software is key to their success.
If you drive a car, use a phone, or travel to Mars, chances are you'll encounter ethernet technology Kevin and Doug have helped foster. Along with guest co-host Chris Norman, we take a deep and nerdy dive into the world of open source software and ethernet and learn how it impacts all our lives.
Katherine Druckman:
Doug, please tell us the history of open source and Intel Ethernet.
Doug Boom:
You really have to hop in the way back machine if you want to talk Intel Ethernet and Linux*. And in some regards the history goes back even further than that. Intel has been with Ethernet since its founding with the old original DEC*-Intel-Xerox* consortium that created the first standards that then became 802.3, which we now call Ethernet. And out of these roots we started with ISA buses and 8 bit cards and all sorts of crazy stuff like 2 - 2 1/2 megabit cards where you had vampire cables where you had to actually physically cram things through cables by stabbing them very violently.
When I joined Intel Ethernet in 1995, we were coming out with something that the industry was calling “fast Ethernet.” And now today's Ethernet is 1000 times faster than that. It was 100 megabits back then in 1995, and we're doing 100 Gigabit products now. It has been an amazing ride.
Intel really got involved, and every time a new OS would come out, we would want to make sure that our products were available so that customers could enjoy Intel Ethernet on all the newness, and so things like Windows NT*, SCO* 5 and SCO 3, UnixWare* and NetWare*. The late 90s was an explosive period for operating systems, including this plucky little one out of Finland.
A lot of people's first experiences with Intel Ethernet were actually through a driver that a gentleman named Becker was creating. He was a NASA* employee and we were getting support calls like, “Hey, can you help us make this driver work a little bit better?” We still have all the files from back then, and I was looking at them before this call with you today, and the changelog says that we built on the 2.2 kernel now. So, it really shows how far back we've been doing things.
If you read the participants for ETH tool, a lot of those names are Intel Ethernet employees, now moved on to some other things in some other cases, but Intel Ethernet has continued to be an active and willing participant in the Linux and open source environments.
Chris Norman:
It was quite astounding how many different drivers we were supporting at one point. I remember when we had a big challenge because we couldn't fit all the drivers we wanted to distribute on one floppy disk. And then we had to go to distributing them on a CD-ROM, and we had CD-ROM duplicating machines that were spinning up all these driver releases.
Doug Boom:
During that time frame I was the product technical lead for those heady days and I actually handcrafted the first CD-ROM that we had to release on because we used to edit files to remove, because we actually had to count sectors on the floppies. Even though we had room for size, sizes took up sectors and if you ran out sectors then you just couldn't load more stuff on to the floppy and so that was what pushed us over to CD-ROMs.
As I was tidying up my desk a couple days ago, I literally still had the old first build where it was the first CD-ROMs that we'd ever done. It was like 12 OSes that we were supporting simultaneously at that time, and it was quite a burden, and we could quickly see why Linux was going to dominate the Unix space because it was open source. It had so much ability to be customized and enhanced in ways that all these closed source alternatives just weren't able to compete with, and we were all very surprised by how fast it took over, but because we had invested in it at the bottom, we were in a great position to be in the kernel with the E100 driver, the E1000 driver, ixgbe, ice these days. Intel's history is all over the kernel.
Chris Norman:
And it wasn't just writing the drivers. We actually had a very extensive compatibility test lab as well.
Doug Boom:
Our testing team was called software evaluation and test and of course that acronym is SWEAT and they had T-shirts.
Katherine Druckman:
We're so good at naming things!
Doug Boom:
“We sweat so our customers don't have to!” That was the tagline for the team and their official name was like Network Quality Labs, or NQL. I worked with a lot of really great testers that were really pushing the product to its limits because we knew that's what customers were going to do with it. They will take it to strange and unusual places, of which we've seen plenty, and failure is not an option in some of these cases. That was what the testing provided.
Katherine Druckman:
I love these history lessons because I'm very much at the top of the stack, working so far away from this type of important, foundational technology. It's the kind of unseen magic that happens at a very fundamental level that a lot of us take for granted, and hearing these stories and this evolution leads to greater appreciation.
Chris Norman:
We do all take it for granted, and back in the days when 10/100 Gigabit was coming out, you plugged the cable in and the light came on and you were golden. But to get to that point, there was a lot of engineering work that went on. Though, we had some extremely intelligent people that were doing the engineering work to make the transition from 10 to 100 happen, 100MB to gigabit to happen, and after my time, I'm sure gigabit to 2.5 and beyond.
Doug Boom:
People just don't realize how pervasive Ethernet is in modern society, and I have argued repeatedly that it's not so much the information age as it is the Ethernet age because its interoperability, its deployability, and its cost point for performance has made information distribution to be so trivial that nobody notices that it happens.
I like to do stuff like stand in a store like some warehouse provider or something and just spot 150 Ethernet ports that I can see. They're in your TVs, they're in your cars, they're in your planes, trains, medical equipment, the financial institutions all operate off of it, and whole bank networks. One of the stories that I used to love to tell was that you don't go to college or jail in the state of California without Intel Ethernet being a participant. We've been involved with the Olympics since the Olympics started streaming in 2000.
And as we start deploying things like vRAN* and the 5G wireless networks, all that data haul has to come over Ethernet as well because it's only wireless until the access point and then it's all wired from there.
Katherine Druckman:
In one of our recent episodes with Jorge Castro, Jorge said, “if the Linux kernel suddenly disappeared, the next day there would be zombies.” I don't even want to imagine what would happen if suddenly Ethernet device drivers didn't work.
I'd really like to pivot over and get Kevin's perspective a little bit more and go on a technical deep dive.
Kevin Bross:
One of the areas that I focus on is synchronization and timing.
Back in 2004, IEEE created a standard called 1588, Precision Time Protocol to allow synchronization between different nodes, and it accounted for how long the cable was. You could basically have two different nodes that were totally on different times, and it would slowly work its way together so they were operating both scintillously at the same rate and then synchronously, but they both had the same sense of time at the same time, and that was that was with the with the original 1588 version one. Then in 2008 they came out with an updated version, 1588 version 2, which is what most people use today. That is used all over the place for synchronization in manufacturing, in audio/video, and my area of expertise is in is in 5G and wireless communications. It's used in financial transactions, gaming, and all sorts of things where you need systems to be able to have the same sense of time.
There is a maintainer of the 1588 code, a Linux PTP project which is on Sourceforge that Richard Cochran maintains, and he's done a wonderful job over the years helping to shepherd it through. There are a number of Intel contributors and some ex-Intel people that are helping to maintain this. A recent release had roughly 50 or so contributors who helped add additional capabilities. And so, they're adding new capabilities that allow us to provide synchronization between devices, and adding capabilities so you can have multiple network controllers in a system that are synchronized to each other over hardware signals. We call them SDP software defined pins that are time-aware GPIO signals, and we're able to actually have multiple NICs within a system.
I'm talking to network providers who are looking at wanting to have, you know, 29 or 30 NIC ports in a server to handle all the different radio heads they have, for example. When you look up at a radio head, you'll see these triangles up there and sometimes you'll see four or eight different radios on each face of the triangle. Let's say there are eight up there on three sides. That's 24 different radio heads up there. And typically that's 24 different Ethernet feeds that need to go into there from the base station to feed those radios.
We have these systems where to meet the 3GPP requirements for LTE or for 5G, in order to do a handoff between cell towers, you have to be synchronized to within 3 microseconds of the opposite device. Typically everybody tries to have every cell tower to be within 1 1/2 microseconds of GPS time, so that way any two of these are within 3 microseconds of each other and you can do those handoffs. But when you when you get into some of the more advanced features, we're looking at things that are sub-microsecond in terms of the synchronization requirements, and we have increasing requests from service providers and from some of the big data center folks to be able to get timing down into the double digit and single digit nanosecond type of timing.
So, we're doing things like we've designed timing synchronization cards like our Westport Channel(Intel® Ethernet Network Adapter E810-XXVDA4T) and Logan Beach (Intel® Ethernet Network Adapter E810-CQDA2T) cards that have built in synchronization capabilities; they have OCXOs, oven-compensated oscillators on board that can provide 4 hours of hold over time. If they lose all timing sources, they can stay within 1 1/2 microseconds for four hours. The accuracy of these oscillators is like one part per billion versus temperature, whereas our normal oscillators are about 50 parts per million. So that's about a 50 thousand times differential in precision. We even have built-in GNSS modules. We can get access to the satellite time and provide synchronization and provide timing signals out.
We're doing all this based upon open source software from the Linux PDP Project and that's all very useful. Our customers like that it's not something Intel hidden and secret. Doug talked about how we're very open with it. We're using this open source software and people can go and can use it and can make adjustments as they see fit.
Now, more recently, we've started getting into what we call Synchronous Ethernet. Whereas with the Precision Time Protocol we would send out packets to synchronize things back and forth, Synchronous Ethernet uses the symbols that are coming down the Ethernet wire to provide synchronization at a hardware clocking level through the Ethernet symbols.
When we wanted to offer that out to the community, it was an interesting bit of a jump ball because we came up with software that we call SyncE 4L. We wanted to put it in with the Linux P2P project, but that didn't quite seem to work.
We ended up having to create a separate repository for it, and we’ve run into this again recently, but in all these cases we're able to get things out and put them out into the open source community so we can get contributions from the broader community.
For more of this conversation and others, subscribe to the Open at Intel podcast:
- Openatintel.podbean.com
- Google Podcasts
- Apple Podcasts
- Spotify
- Amazon Music
- Or your favorite podcast player (RSS).
About the Author
Katherine Druckman, an Intel Open Source Evangelist, is a host of podcasts Open at Intel, Reality 2.0 and FLOSS Weekly. A security and privacy advocate, software engineer, and former digital director of Linux Journal, she's a long-time champion of open source and open standards.