Intel Ouroboros: Pat Gelsinger Returns to Build the Future

Classical Ouroboros. Wikipedia.

Pat Gelsinger is a technologist’ technologist. He worked on the X386 and X486 processors. We referenced the book he and Crawford wrote Programming the 80386 for our Porting Unix to the 386” series in Dr. Dobbs Journal in the early 1990’s and the development of 386BSD. It was a seminal processor and work that helped launched the open source operating system movement.

Yet Pat didn’t stay to retire with laurels at Intel. After many years battling for Intel’s future, he left to head EMC and, later, VMWare. Now he’s been brought back to Intel as CEO effective 15 February 2021. Why?

In a nutshell, while Gelsinger was off dabbling in storage technologies and cloud services, Intel was burning through every single technology advantage people like Gelsinger had built. Now, Intel is facing a reckoning, and needs to build a future again.

And that future depends on people with technical and domain skill, like Pat Gelsinger. 

This was a bitter pill for Intel’s Board of Directors and executive team to swallow. But, as Baron Mordo said, “The bill comes due”

The roots of this squandering of the future was based not in technology, but in contempt of technologists. Risk-takers in both strategic and startup investment in the 1990’s and 2000’s saw the proliferation of new approaches as “chaotic”. 

InterProphet SiliconTCP board. 1998.

I sat in an office of a top tier VC firm on Sand Hill Road in the late 1990’s and listened to the “smart money” partner complain about how their investments in ATM were being disrupted by InterProphet’s SiliconTCP low latency chip — as if I owned the burgeoning TCP/IP technology and was personally damaging their investments with a few prototype boards, a handful of working FPGAs and some Verilog.

TCP/IP was present in the mid-1980’s in Berkeley Unix, and used in datacenters throughout academia and government. As Vint Cerf himself noted, it was a good enough solution to get packets from one point to another.

TCP/IP as an “ad hoc” technology was good enough to take out OSI, ISDN and ATM. I thought it was wiser to surf the tsunami instead of railing against it. That just bred resentment.

I sat in corporate offices in the 1990’s and 2000’s and heard complaints about how open source was overtaking proprietary software stacks, and it was ruining their projections and their business.

Berkeley Unix was a feeder of innovation from the early 1980’s. True, it was not a viable competitor to proprietary OS stacks until we launched 386BSD in the early to mid-1990s. From that open source stack, backed by Dr. Dobbs Journal, sprang a whole host of proprietary software industry competitors, including Linux.

Open source kernels like 386BSD and its many progeny would not have made inroads if there had not been a wealth of innovation already present to mine out by these groups — innovation that was neglected, minimized or attacked by established proprietary players. 

But up to the point we released 386BSD publicly, everyone underestimated us. It couldn’t be done. It wouldn’t be done. But it was done. I knew it could be done.

I sat in a room in the early 2000’s as a VP at Microsoft complained about how open source was a threat and how, looking right at me, they had gathered information on everyone involved and their families. As if developing the open source OS created some kind of ominous fifth column of open source software subverting their eternal rights to OS glory. It was…unpleasant. It was also incredibly horribly damaging personally.

I listened in the mid-2000’s as a VC “sympathetically” told us that we’d never get funding again after InterProphet. Not because we’d done anything wrong. We met our commitments. We built things. But because they didn’t want innovation and the risks that came with it. And their way to kill the message was to kill the messenger.

“The bill comes due”.

The resentment in the 1990s and 2000s towards new ideas and the creation of new products was intense. All they could see was damage to their five year technology plans and prior investments. The idea of hedging your bets was anathema, because that implied they couldn’t control the industry.

And mind you, it was about control. Control of technology. Control of innovation. Control of monetization. Control of creativity. Control of thought.

So here we are, in 2021. Intel squandered their future, slicing and dicing their monetization game. Intel’s “safe and sane” business relationship with Apple is now in pieces. In 2018 Apple maneuvered Intel into taking out Qualcomm as a competitor. In 2019 Apple acquired Intel’s smartphone modem tech and developed their own. In 2020 Apple introduced the M1 as a competitor to the high end X86 line. And that’s just one customer. The vultures are circling. Intel lost control.

Now Pat Gelsinger has agreed to come back. How will he pick up the pieces of a damaged company? I assume he’d only return if he had broad latitude in restructuring, hiring and firing. He’ll investigate interesting acquisition targets that offer a path forward for Intel. And he’ll look closely at how rivals like AMD under Dr. Lisa Su have done so well while Intel foundered.

Intel ouroboros. Pat is back at the beginning. It remains to be seen how he creates a future for Intel once again.

Married Founders: The Times they are a-Changin’

I was reading this article on how married co-founders are getting acceptance — and investment — and it’s not a bad thing. And it provoked a memory.

UC Berkeley Physics Department image used in video production.

When I worked with the University of California at Berkeley Physics Department, my alma mater, to enhance their fundraising efforts, I developed and field tested with them an instant video production system for alumni. The idea was to not just ask for money, but to ask for experiences, like what was their favorite experiment in 111 Laboratory. These experiences in video were then emailed to a server array which instantly provided correction (sound, video, format, etc) and encased the video into a custom designed template with music and background reflecting the Cal Physics environment. The completed video was then emailed to the Director for approval. All she had to do was say yes, no, or maybe something else. If she liked it, it was automatically posted to a website dedicated to Berkeley Physics. It was cool. I even wrote a paper on the results for the ACM.

At the same time, the Haas Business School launched a business plan competition for Berkeley students, faculty and alumni. So I decided to enter it. This wasn’t my first BBQ, so to speak — I had gotten funding for InterProphet some years earlier, and that was a harder sell given how VCs gave up on hardware investments in the early 2000s and moved to Internet companies. But this *was* an Internet company — a fully developed video production system and mechanism where no one had to learn editing software to make a production-quality video.

Yes, folks said I was ahead of my time. Yes, investors quibbled over why was I doing this with software and not, say, with Chinese or Indian workers manually handling production — they had a massive obsession with using folks instead of using automation then. They questioned whether video would ever become popular on the Internet given latency issues (I was an expert on this BTW, since InterProphet was all about low-latency). This was before YouTube, so it was hard for old-style VCs to get their heads around video on the web.

But the most insulting response I received was not from VCs or angels, but from the Haas Business School at Berkeley. For a university known for progressive insight, the worst response to my business plan was not about TAM or competitive advantage or technology or experience — it was about how the anonymous reviewer would “NEVER” invest in a husband-wife company, as they had been burned once before. It was bigoted. It was unfair. It was vile. And he killed any prospects of working with Berkeley.

Relevant part of the review by the Haas Business School business plan competition of ExecProducer and my work with the UC Berkeley physics Department. Apparently, having “Relevant domain experience, industry experience, business track record, education, network, etc” was tainted by the stain of married co-founders. Yes folks, that killed it. (Photo: R Jolitz)

Needless to say, this was also offensive to the Berkeley physics Department as well. I was one of their alumni and they worked with me. It was a validated concept. But that Haas Business School reviewer poisoned the waters in the larger investment community, and the company I had labored to move from Zero to One was dead in the water. Silicon Valley is a small community — or at least was small back in 2004.

I’m pleased to see the times they are a-changin’. I hope my struggles paved the way for a new generation of young people to be considered for investment based on their ideas, creativity, perseverance, and character — instead of their gender or race or friendships or “comfort level” (a catch-all for “I don’t like you because your different”). Meritocracy is a lie when it demands you look exactly like the person who backs you. And the last thing we need right now is more lies.

No, it’s not “High Power”, it’s now “Low Power”

You may have heard that servers at Google have been packed so tight they catch fire in the datacenter. Turns out power dissipation is the key – even laptops get hot, and servers stacked are fire hazards. It’s the power, everybody – the limiting factor to communications is power (according to Broadcom). What a difference a few years make. When I was invited to a meeting about InterProphet and SiliconTCP over at a major infrastructure company back then, the gal assigned to evaluate my work laughed at me when I seriously brought up the issue of low power and TCP. Of course, she also wanted to boast about some thesis she’d done on TCP about twenty years after everyone else. One (male) engineer, in hearing the description of the meeting said it was the first all-woman “pissing competition” on record. I told him just because I’m assigned a woman for due diligence because I’m a woman too doesn’t mean I get a free ride – frequently it’s the opposite. Alas, there’s no secret sisterhood in business, but envy is universal.

So, how do you swap hot hotswap servers? The key is low power TCP – you can’t burn out the stack anymore adding more and more processors (not to mention the management overhead) even in the datacenter (sorry Intel). You need to get the lowest power TCP stack possible. And that means a no-processor design.

The nontech “what does a low-power TCP hardware implementation do for me” (what a mouthful) is you get real full video on cellphones without burning out the battery as quickly. Since I’m doing automated full video production these days, that’s kind of my interest too. Paul Baran wrote the basic patents on cellular communications for audio/video. But he couldn’t achieve it fully because of this limit. He was so far ahead of his time it’s amazing. I wonder what he’d think now?

So Silicon Valley isn’t really dead technologically, despite what some people like to say. There are a lot of technology problems still to be solved, discussed in black and white in some legendary patents and papers from people like Baran that created entire industries. It’s all right here. When I read patents, it’s pretty clear to me that “everything *hasn’t* been invented yet”.

Unix was invented when I was in high school. The Internet – gee, it was old hat at Berkeley when I got there. Packet-switching? Baran. Cellular. Baran et. al. But no one man or woman could anticipate *everything* because a lot of the pieces just weren’t in place. So the inventors carefully outlined why things couldn’t work, or came up with nonviable solutions because of these missing pieces. It’s all there – if anyone wants to take the time to read it.

Come On Charlie Brown, Just Kick the Football

Love the “Lucy holding the football for Charlie Brown” quote by Nathan Brookwood in CNET about the Dell / AMD relationship. It always seems so close, and then it slips away. Intel always holds the relationship.

Nathan may be right in saying last year it came the closest ever because of Intel’s slips in so many areas. But instead of running with the ball, AMD fumbled by assuming they could rely solely on their 64-bit advantage for the sale. That isn’t enough I was told. One exec who’s negotiated agreements with Intel and AMD and companies like Dell told me that AMD needs to get “the whiphand” on Intel in some way to get the Dell close. AMD doesn’t have that whiphand. And I know why. It came up chatting with an editor who wanted to know the background on Intel’s preannounced new product. You see, he knew I’d been there, so he wanted the story again. So here it is…

A ROSE is a ROSE – Reordering Segment Engine

Ashlee Vance wrote that Intel will be introducting “I/O Acceleration Technology” to “attack greedy TCP/IP stack” consumption – in other words, latency through the stack. “Customers often find that their servers spend an inordinate amount of time dealing with network traffic when they should be hammering away on application data.” This sounds very familiar – we told them years ago that “all processors wait at the same speed”.

Back in 1997, when I filed a provisional patent on just such an approach, I had an interesting meeting with Intel’s processor side. We called the technique ROSE then, for Reordering Segment Engine for a product we envisioned called the Network Accelerator – and yes, this was before Adaptec and Alacritech and all those other TOE guys. It was the first in a series of parallel processing refinements, which dealt with the layer 2-7 issues of TCP/IP (the discussion was under NDA).

SiliconTCP, EtherSAN, and Scalability

Everyone says I was amazingly ahead of my time. As Rick Merritt, EE Times writes about the possibility of using storage interconnects concluding “Competitors such as Broadcom Corp., which have existing 1-Gbit R-NICs, will not be able to scale to the greater bandwidth because they lack the ASIC state machine architecture…”.

Well, now I’m pleased that I wrote a paper for the global storage network workshop last MayAll You Need is TCP: EtherSAN and Storage Networks, and even more grateful for the feedback I received from people like Jim Grey of Microsoft, John Wakerly of Cisco, and Greg Pfister of IBM. Gordon Bell was an earlier advocate of the InterProphet technology and urged Chuck Thacker to take a look at it several years ago. So it appears this is finally becoming a topic of serious consideration – although I’ve been seeing it coming for many years.

The fundamental scalable state machine architecture patent (“TCP/IP network accelerator system and method which identifies classes of packet traffic for predictable protocols“) was filed in 1997 and granted 2000. A term memory patent (“Term Addressable Memory of an Accelerator System and Method was independently filed and granted July of 2004. It’s a better memory approach that hand-in-glove with a state machine architecture that deals with certain flaws.

Term Memory Patent Parchment Looks Lovely and Feels Great!

OK. I know the patent attorney said I got the patent grant (“Term Addressable Memory of an Accelerator System and Method“) a while ago, but it really is different when you actually hold it in your hand! I was so excited that I told Vint Cerf about it and ever gracious, he said “congratulations, Lynne – persistence counts!” Means a great deal to me to hear that from the “Father of the Internet”.

It’s my 2nd parchment but there’s more in the queue. This patent relates to the limits found in the original design for InterProphet discussed in the SiliconTCP paper I put together earlier this year. Work on this patent was done after went into a low-key mode because of a lack of commitment to it as private venture. But just because it’s easy to bet against someone knowing that life isn’t fair, that doesn’t mean it’s right. Karma rules!

I’m happy to keep my word and execute it well. It just takes a bit more time to make it to shore when the winds are set against you. But winds shift, and so do trends.

What, me worry?

This little article just in from a dedicated Cisco engineer. Looks like Cisco is taking a “broadside” from Broadcom in the “TCP offload” universe.

Of course, notice the weasel words of “selected network streams”. In contrast, at InterProphet we showed a 10x advantage of all network streams on NT at Microsoft in their offices in Redmond in 1998 with a patented design.

So it’s taken Broadcom and Microsoft working together about 6 years to kind of make something work but not really. Not very impressive.

And SiliconTCP works for Unix and other OS’s as well. You don’t have to use Windows to get the benefit. In a world of “choice”, shouldn’t a chip be OS-agnostic? Or do they think choice is a bad idea?

Don’t know how often I read about a TCP offload mechanism which doesn’t really do the job. If a network stack worked like these chips, the Internet would be a lot more frustrating a place.

But I doubt Cisco cares, even though their engineers do. With China’s massive Huawei on the bottom end and ruthless Broadcom moving in, don’t bet on Cisco to defend their turf. After all, they’re too big to beat, right? And if a company lets things go long enough, figuring that “someone else I like better will invent it”, they take the risk someone they don’t like will do it.

Flamethrowers and Memories

Alex Cannera dropped an interesting paper on my desktop discussing congestion control in grid networks. And it’s results confirm what I and others have seen over the years; Vint Cerf seriously saw in 1998 that hop-by-hop reliability preserving end-to-end semantics in the routers was the real key to handling this issue. Vint also is a renowned wine expert, and treated me and William to a wonderful tour of fine wines at the Rubicon Restaurant in San Francisco where we had a memorable discussion on exactly this issue.

Of course, their terms-of-art are different from mine, since we all seem to invent new terms. So their “network of queues” is my bucket brigade mechanism. And their test demo is similar to one at InterProphet we called FlameThrower devised by Senior Hardware Engineer Todd Lawson and Software Engineer Madan Musuvathi to literally flood the other side with packets and see if it falls over.

Todd and Madan built a wirewrap version of SiliconTCP on a DEC PAM card with a NIC wired on (and that’s exciting with 100MHz logic). We demo’d this to Microsoft, venture, and lots of other companies back in Summer 1998. I have the wirewrap on my wall alongside a production board.

But the solution presented in this paper to “back pressure” the plug by disabling TCP congestion control selectively is where we part company. Herbert and Blanc/Primet quite correctly point out some of the barriers to FAST, Highspeed TCP / Scalable TCP, and XCP, but then fall back on the old link layer solution approach (which we diddle in the stack software). If only it were that simple.

Reliable link layer isn’t enough, and Vint (in looking back) clearly knew this. That’s why he saw SiliconTCP as fitting best here. This was the key reason he joined the board of InterProphet so many years ago.

Many people have made reliable link layers. We’ve done it with the boards we have here right now. But no one else made a reliable network and transport layer that spans many hops, maximizing the capacity of the aggregate network. Our boards also do this. So we did demo Vint’s vision in practice.

It’s only now that people are starting to thrash the problem that Vint saw many years ago. But they lack his insight as to the real nature of the problem. It isn’t turning off congestion control — it’s using it effectively.

So long as engineers think the answer is a simple “stack hack” instead of rethinking how to more effectively meet the protocol demands — not new protocols, not turning off the congestion, not cheating by biasing fairness — but really simply doing our job better, we’ll continue to run into this problem.

Sometimes a Legend

And once again, an interesting item in the postel.org end-to-end group – “An interesting version of TCP was created a few years ago at a large data-storage-system company here — essentially, the TCP receive window was reduced to Go/No-Go, and startup was modified, so the sending Unix box would blast to its mirror at full wire rate from the get go. ACKs would have meaningless Window values, excepting 0, because sender and receiver had similar processing/buffering capability. Loss produced replacement, via repeated ACKs. Being LAN-based system overall made all these mods workable. But clearly, the engineers involved found normal TCP wanting in the ability to deliver data on high-speed links.”

Interesting how legends develop. This project was called the flamethrower demo done with a wirewrap version of SiliconTCP on a DEC PAM card with a NIC wired on (and that’s exciting with 100MHz logic).

We demo’d this to Microsoft, venture, and lots of other companies back in Summer 1998. One Microsoft exec (Peter Ford) noted that we were so overloading the standard NICs that an “etherlock” condition was likely to occur. Etherlock, for those who don’t know, occurs when all of the bandwidth is consumed and nothing else can communicate because there is no idle time effectively. And yes, we saw this occur.

One of the more interesting things we found is that many “standard” NICs were not standard compliant. I still have the wirewrap on my wall alongside a production board.