From Sun Microsystems StarCat to Vera Rubin: (V2)

Author’s Note: Following the release of my first piece on StarCat, I received valuable feedback from experienced industry peers. This v2 expands on the architectural mechanics of cache coherency and the critical shift from broadcast to directory-based fabrics. It is an evolution of the original narrative, optimized for readers who want to see the gears beneath the silicon.

Original link here: From Sun Microsystems StarCat to Vera Rubin: When System-Scale Computing Became Real: (V1) | by Shankar Ravi | Jan, 2026 | Medium

This article reflects my personal views and opinions only and does not represent the views of any past, present, or future employer.

Scope note: The goal here isn’t to dive into the mechanics of MESI, directory protocols, or fabric internals. Instead, the focus is on higher-level memory pressure patterns and how similar forces have surfaced across data center eras.

Introduction

I joined Sun Microsystems in the early 2000s, when StarCat (Sun Fire 15K) represented the absolute limit of shared-memory, scale-up computing. It was the pinnacle of brute-force enterprise design — and a masterclass in both ambition and constraint.

The evolution from Sun’s StarCat to NVIDIA’s NVL72 — and now the Vera Rubin generation and the emerging UALink — marks a historic architectural shift in how training and inference workloads are built and scaled:

From broadcast-heavy shared memory to directory-switched, system-scale fabrics.

This is not a story about vendors. It is a story about coherency, scale, and the hard limits of physics.

StarCat and the Broadcast Wall

StarCat attempted something audacious: treating more than 100 CPUs as a single coherent machine.

At full scale, the system relied on:

• Broadcast-style cache coherency
• A massive Fireplane crossbar
• Aggressive signal-integrity and timing engineering

The design pushed snoop-based coherency to its architectural limits.

What Is Snoop-Based Coherency?

At its core, snoop-based coherency works by broadcast.

Every processor cache continuously monitors (“snoops”) memory transactions on the interconnect. When one CPU modifies a cache line, all other caches observe the transaction and either invalidate or update their own copies to remain consistent.

This approach works well when:

• The number of CPUs is small
• Latency across the interconnect is relatively uniform
• Broadcast traffic is manageable

Early SMP systems succeeded because broadcast was simple, fast, and predictable.

What “Large Scale” Actually Means

“Large scale” does not mean faster CPUs or higher clock speeds. It means adding more processors into the same cache-coherent domain.

Small Coherent Domain

• Example: 4 CPUs
• One cache write triggers: 3 snoop responses

Effect:

• Low coherency traffic
• Predictable latency
• Negligible broadcast overhead

At this scale, snooping works well and feels almost free.

Larger Coherent Domain

• Example: 64 CPUs
• One cache write triggers: 63 snoop responses

Effect:

• Coherency traffic dominates the interconnect
• Latency grows non-linearly
• Timing becomes unpredictable

Even if only one other CPU actually cares about the data, all caches must still observe the broadcast.

The Key Insight

As CPU count increases:

• Useful computation scales roughly linearly
• Broadcast coherency traffic scales with the number of participants

Eventually, the system spends more effort maintaining coherency than executing work.

This is the broadcast wall StarCat exposed.

Send Mondo Timeouts: When the OS Loses Control

One of the most visible failure symptoms at StarCat scale was Send Mondo timeouts.

In Solaris on SPARC, a Mondo was an inter-processor interrupt (IPI) used for critical OS coordination such as scheduling decisions and TLB (Translation Lookaside Buffer) shootdowns. The sending CPU expected a timely acknowledgment. When that acknowledgment failed to arrive within a defined window, the kernel reported a Send Mondo timeout.

One of the most common reasons for sending a Mondo was a TLB shootdown. The Translation Lookaside Buffer is a small, fast cache inside each CPU that stores recent virtual-to-physical address translations. When the operating system modified a page table entry — during memory unmapping, protection changes, or process migration — it had to invalidate stale translations cached in the TLBs of all CPUs that might have accessed that address.

This required sending IPIs to those CPUs and waiting for acknowledgments before execution could safely continue.

At small scale, this coordination was fast and reliable. At StarCat scale, however, TLB shootdowns amplified the cost of broadcast coherency. Frequent, latency-sensitive IPIs now competed with an already saturated fabric, turning routine memory management into a system-wide synchronization hazard.

Think of a Mondo like a tap on the shoulder between coworkers:

• In a small office, it’s instant.
• In a stadium where everyone is shouting, you never hear the tap — and work grinds to a halt.

The target CPU was often alive and healthy — but the fabric could not guarantee timely delivery.

The operating system could no longer reliably coordinate its own CPUs.

Send Mondo timeouts were not a bug. They were a symptom of an architectural limit being crossed.

The Intel Commodity Interlude: When Scale-Out Won

Between StarCat and today’s AI factories, the industry took a long detour.

Instead of one large coherent machine, the industry built many smaller machines.

The reason was not a lack of architectural interest in large cache-coherent systems. It was that the dominant workloads no longer justified the cost and complexity of fixing cache coherency in hardware at that scale.

Enterprise and internet workloads favored:

• Throughput over single-image latency
• Failure isolation over tight coupling
• Horizontal growth over vertical expansion

Building StarCat-class coherency in commodity silicon was technically possible — but economically unjustifiable.

As a result, the coherency problem moved up the stack.

MPI, distributed file systems like HDFS, data-parallel frameworks such as Hadoop and Spark, and later orchestration platforms like Kubernetes absorbed consistency, coordination, and failure handling that hardware no longer provided.

The industry didn’t abandon coherency because it was unimportant. It abandoned it because, for that era’s workloads, software was the cheaper place to pay the price.

What Is Directory-Based Coherency?

Directory-based coherency replaces broadcast with targeted coordination.

Instead of every cache snooping every transaction, the system maintains a directory tracking which processors hold a copy of each cache line. Requests are routed only to relevant participants.

NVL72: Bypassing the Scaling Wall

NVIDIA bypassed the coherency wall with NVL72 by redefining the system boundary.

Rather than treating GPUs as peripherals, NVL72 treats the entire rack as a single, vertically integrated GPU fabric.

This achieves StarCat-scale shared memory without broadcast.

Vera Rubin: From Rack-Scale Acceleration to Rack-Scale Computing

With Vera Rubin, NVIDIA completes the transition from rack-scale acceleration to rack-scale computing.

By tightly coupling CPUs, GPUs, memory, and fabric, coherency becomes a system-wide contract.

Coherency is no longer an optimization. It is the organizing principle.

The unit of innovation is no longer the server. It is the AI Factory.

Comparing the Two Worlds

At this point, the architectural contrast becomes clear. StarCat, NVL72, and Vera Rubin represent variations of the same scale-up philosophy, while the Intel commodity era represents a fundamentally different approach. The differences are not about vendors, but about how systems communicate, manage memory, tolerate failure, and price scale.

The decisive difference between scale-up and scale-out is not compute — it is whether software thinks in memory or in messages

What Must Change in Software for True Scale-Up

Most of today’s infrastructure and ML frameworks were shaped during the scale-out, commodity cluster era. They run on scale-up systems — but they are not designed for them. As systems return to rack-scale coherence, several long-standing software assumptions begin to break.

From “Distributed by Default” to Locality-Aware Execution

Scale-out software assumes high latency, jitter, and failure isolation. As a result, it aggressively partitions data and minimizes coordination.

Scale-up systems invert those assumptions:

• Latency inside the rack is low and predictable
• Memory can be shared and fine-grained
• Over-partitioning increases overhead rather than reducing it

Frameworks must become topology-aware, treating within-rack execution differently from cross-rack execution.

Programming Models Must Exploit Memory Semantics

Many frameworks still behave as if every interaction is a message.

That made sense when:

• Memory was local to a node
• Everything else was “the network”

In scale-up systems:

• Load/store semantics are preserved inside the system boundary
• Hardware coherency provides correctness guarantees
• Excess serialization and sharding become self-inflicted bottlenecks

The opportunity is not new abstractions, but removing unnecessary ones.

Scheduling and Runtimes Must Become Fabric-Aware

Schedulers such as Kubernetes, Slurm, and Ray were built assuming:

• Nodes are the fundamental unit
• Placement is coarse-grained
• Failure domains are small and isolated

Scale-up systems require schedulers to understand:

• Coherent domains
• Fabric topology
• Shared-fate boundaries

In some cases, the rack — not the node — becomes the scheduling unit.

Fault Handling Must Shift Left

Scale-out software expects failures and recovers by retrying or restarting work.

Scale-up systems operate closer to the edge:

• Failures are rarer but more expensive
• Restarting a massive job is not trivial
• Hardware RAS exists specifically to avoid full restarts

Frameworks must integrate more tightly with hardware telemetry, preferring containment and graceful degradation over brute-force recovery.

Observability Must Become System-Scale

Traditional tools focus on:

• Node-level bottlenecks
• Network congestion

Scale-up systems demand visibility into:

• Coherency traffic
• Fabric-level latency
• Memory behavior across CPUs and accelerators

Performance debugging moves down the stack, closer to the hardware.

Where This Applies to Inference

These shifts matter most for system-scale and memory-bound inference — such as large models, long-context workloads, and high-throughput inference operating at high utilization. In these cases, shared memory, predictable latency, and reduced software barriers directly translate into efficiency gains.

By contrast, stateless, request-driven inference — small models, microservice-style deployments, and edge inference — will continue to favor scale-out architectures, where failure isolation and cost efficiency dominate.

The Core Shift

Scale-up systems don’t just need faster hardware — they need software that trusts hardware guarantees again.

For two decades, software learned to distrust hardware and compensate with abstraction, retries, and redundancy. Scale-up reverses that relationship.

What Comes Next: UALink

NVLink is a walled garden — tightly optimized and vertically integrated. UALink is the attempt to build a public park — open and heterogeneous.

The question is whether the park can ever be as well manicured as the garden.

History Has a Rhythm

The inference era may end up echoing the x86 transition all over again.

Training rewards extreme vertical integration and tightly coupled system-scale designs. Inference shifts the optimization target toward cost, power efficiency, deployment scale, and operational simplicity.

This mirrors the early 2000s, when bespoke SMP systems gave way to commodity x86 clusters — because they were good enough, cheaper, and deployable everywhere.

The technology changes — but the shape of history repeats.