Processor latency is a critical perfomance issue for real-time data acquisition (DAQ) applications. On 06/25/2026 I asked Google Gemini Pro to elaborate how different intel processors behave with respect to latency. The focus is on comparing the new Core Ultra processors to older models that already have a proven track record for DAQ applications.
Topics:
Answer: The shift from the traditional Intel Core “i” series to the new Core Ultra lineup represents one of the most significant architectural changes Intel has made in a decade. While it drastically improves power efficiency and integrated graphics, the physical separation of components has introduced new latency hurdles.
Here is the breakdown of why this happens, what the architecture is called, and how enterprise Xeon chips handle the same physical challenges.
Intel’s tile-based architecture is built on a 3D packaging technology called Foveros. Instead of printing the entire processor on a single, flat piece of silicon (a monolithic die), Foveros allows Intel to print distinct “tiles” (a Compute tile, a Graphics tile, an SoC tile, and an I/O tile) using different manufacturing processes, and then stack them vertically on top of a base layer that wires them all together.
The legacy Core “i” series (like the 13th and 14th Gen Raptor Lake chips) were primarily monolithic. All the CPU cores, the L3 cache, and the memory controllers lived on the exact same piece of silicon, connected by a high-speed “Ring Bus.” Data traveled incredibly fast because it didn’t have to cross any physical gaps.
With the Foveros tile architecture in Core Ultra, Intel disaggregated those components. This introduces three major latency penalties:
Modern Xeon processors (starting aggressively with Sapphire Rapids and continuing into Emerald Rapids and Granite Rapids) also use a tile/chiplet architecture. However, they do not use the consumer Foveros stacking method. Instead, they use a technology called EMIB (Embedded Multi-die Interconnect Bridge) to connect massive compute tiles side-by-side.
While Xeons face the same physical laws of die-to-die physics as Core Ultra, they are designed for data centers where latency and bandwidth are critical. They mitigate the latency penalties through entirely different engineering choices:
Answer: Yes, they are fundamentally different. In fact, managing sleep states (technically called C-states) is exactly where Intel’s new tile architectures diverge the most from legacy designs and from each other.
Because the physical layout of the chips dictates how they power down, the monolithic, mobile-tile, and server-tile designs handle idling in completely different ways. Here is how the three architectures manage sleep states:
In a monolithic chip like a 13th Gen Core i9, everything—the cores, the L3 cache, the memory controller, and the graphics—lives on a single piece of silicon connected by a Ring Bus.
The Core Ultra architecture was designed almost entirely to solve the monolithic sleep problem. Because the chip is broken into independent tiles, Intel can shut down entire physical sections of the processor while leaving others awake.
While modern Xeons are also tiled, their approach to sleep states is driven by the demands of the data center, where responsiveness (latency) is far more important than saving battery life.
Summary: Legacy Core “i” puts individual cores to sleep but keeps the house awake. Core Ultra turns off the main house and lives in the guest house to save maximum power. Xeon refuses to go into deep sleep because it has to be ready to answer the door at a microsecond’s notice.
Answer: Yes, there is a massive divide within the mobile Core Ultra lineup when it comes to real-time data acquisition. If you are trying to capture high-frequency streams without dropping packets or overflowing buffers, the specific tier of the processor and its thermal envelope dictate whether the architecture will fight you or support you.
For real-time, low-latency tasks, you must look exclusively at the H-Series (or the newer Series 2 / Arrow Lake-H models), and completely avoid the U-Series and V-Series. Here is exactly why certain models are better suited for your acquisition environment, and the hardware hurdles you need to navigate.
Real-time data acquisition requires sustained, predictable clock speeds.
When you are writing the core acquisition loops in C or C++, the most reliable way to defeat the latency of Intel’s Thread Director is to use thread affinity. You explicitly lock your data-polling thread to a specific Performance Core (P-Core) and forbid the Windows scheduler from moving it to an E-core.
When routing high-bandwidth data streams through an external PCIe enclosure or a PXI chassis, your physical connection on a modern laptop is almost certainly Thunderbolt.
In the Core Ultra (Meteor Lake) architecture, the Thunderbolt 4 controllers are integrated directly into the I/O Tile. This is both a blessing and a curse. It provides immense bandwidth (40 Gbps), but because it sits on a separate tile from the Compute cores, every DMA (Direct Memory Access) transfer from the PXI controller has to cross the inter-tile fabric.
To minimize the impact of this hop, you need a processor that keeps the inter-tile fabric fully powered up during acquisition. The H-series laptops, when plugged into wall power and set to “High Performance” in Windows, will keep this fabric active. A U-series chip will constantly attempt to power-gate the I/O fabric to save battery, destroying your latency.
If you are sourcing a mobile workstation for this exact purpose:
Answer: The Core Ultra HX-Series completely rewrites the rules for mobile data acquisition. If you are configuring a mobile workstation, the HX models are actually the absolute best choice available, easily surpassing the standard H-Series.
Here is why the HX architecture is the gold standard for latency-sensitive tasks:
The most significant advantage of the HX models is that they are essentially repackaged desktop processors (Arrow Lake-S). Because of this, Intel completely removed the Low-Power Efficient-cores (LP-E cores) from the design. For example, the Core Ultra 9 275HX and Core Ultra 7 255HX have exactly zero LP-E cores.
This completely eliminates the three-tier Thread Director migration penalty. When your acquisition loop wakes up to pull data from the PXI chassis, the Windows scheduler doesn’t have to debate whether to put it on an ultra-low-power tile; the thread stays on the primary compute cores.
While standard H-Series chips hover around 28W to 45W, the HX processors operate with a massive 55W base power and can burst up to a 160W Maximum Turbo Power. With that much thermal headroom, the processor does not aggressively park cores into deep sleep states. This sustained power delivery keeps the die-to-die fabric and PCIe/Thunderbolt controllers active, ensuring that direct memory access (DMA) transfers from your chassis do not incur micro-stutters from waking up sleeping architecture.
The flagship Core Ultra 9 processors (like the 285HX, 275HX, and 290HX Plus) feature a massive 8 Performance Cores (P-cores) alongside 16 Efficient-cores. Even the Core Ultra 7 HX models feature 8 P-cores. This allows you to permanently pin your primary polling loops and hardware interrupts to dedicated P-cores without starving the Windows OS or your user interface of resources.
In short, if you are looking to drive high-bandwidth, real-time hardware over a Thunderbolt connection without dropping packets, an HX-equipped mobile workstation is the closest you can get to true desktop-class stability in a laptop.
Answer: If you are considering moving away from a mobile workstation and building a dedicated desktop for your real-time data acquisition, there are massive caveats you need to be aware of regarding the desktop Core Ultra lineup.
The desktop Core Ultra processors (code-named Arrow Lake-S) suffer from the exact same physical challenges as their mobile counterparts, but Intel recently released a hardware revision that changes the math entirely. Here is what you need to know about the architecture and what to avoid:
Just like the mobile chips, the desktop Core Ultra 200S series transitioned away from monolithic silicon to a disaggregated, multi-chip module design.
Because the memory controller and the compute cores now live on completely different physical tiles, the initial Core Ultra 200S chips suffered a memory latency penalty of roughly 20 to 30 nanoseconds compared to older legacy designs (like the 13th or 14th Gen Raptor Lake). Furthermore, the internal Die-to-Die (D2D) interconnect—the microscopic bridges linking the tiles—was originally clocked at a conservative 2.1 GHz. Data simply took too many clock cycles to shuttle between the Compute Tile and the SoC Tile.
For a high-frequency polling loop, that extra 30ns of memory latency is a severe handicap.
One positive architectural change Intel made for all Arrow Lake desktop chips is how they physically arrange the cores on the silicon.
In older hybrid designs (like the Core i9-13900K), all the P-cores were clustered together in one group, and all the E-cores were clustered in another. In the desktop Core Ultra, Intel physically interleaves the P-cores and E-cores. This layout change was specifically engineered to reduce core-to-core latency if the Windows scheduler forces instructions to move between the two core types.
If you are sourcing a desktop processor to interface with your Thunderbolt hardware, do not buy the original Core Ultra 200S (like the Core Ultra 9 285K or Ultra 7 265K).
Instead, you must look exclusively for the recently announced Core Ultra 200S Plus models (such as the Core Ultra 7 270K Plus). Intel recognized the latency bottleneck of the chiplet design and overhauled the internal power delivery infrastructure for the “Plus” refresh. They boosted the D2D interconnect speed from 2.1 GHz to a blistering 3.0 GHz. This 900 MHz bump (a nearly 43% increase) vastly speeds up the data pathway between the tiles, directly driving system latency down and drastically improving memory access times.
Answer: For a real-time data acquisition system which relies on OpenGL to plot massive amounts of 2D neural data at high refresh rates, the answer to which renderer you should use is entirely dependent on where your monitor is physically plugged in.
In DAQ environments, the latency bottleneck is rarely the raw rendering power of the GPU; instead, it is the physical “plumbing” of how the rendered frames travel to the screen. Here is exactly how you should configure your renderer to achieve the lowest possible latency:
The biggest source of OpenGL display latency in a dual-GPU system is a mismatch between the renderer and the display output. If you tell Windows to render on the powerful discrete GPU (dGPU), but your monitor is physically wired to the Core Ultra integrated GPU (iGPU), the system has to do the following: 1. Render the frame in the dGPU’s VRAM. 2. Package that frame buffer. 3. Send it across the PCIe bus to the iGPU’s memory. 4. Have the iGPU push it to the screen.
This cross-bus copy operation introduces significant overhead, eats up PCIe bandwidth, and typically adds at least 1 to 2 frames of latency (or micro-stutters) to your real-time scrolling plots.
Use the iGPU if: You are using a laptop’s internal screen (without a hardware MUX switch), or if you are on a desktop and your monitor is plugged into the motherboard’s HDMI/DisplayPort.
Because Intel has massively upgraded the Core Ultra Arc graphics, the iGPU is now incredibly powerful. Drawing high-frequency 2D OpenGL lines is virtually effortless for it. By rendering natively on the iGPU, the frame is generated exactly where the display controller lives, completely bypassing the PCIe bus and providing the most immediate, lowest-latency path to the screen.
Use the dGPU if: You are on a desktop with the monitor plugged directly into the back of the discrete graphics card, or if you are using a mobile workstation and have an external monitor plugged into a port that is hardwired directly to the dGPU (many laptops wire their HDMI port to the dGPU and their Thunderbolt ports to the iGPU).
In this scenario, rendering on the dGPU is the fastest path, as the display controller on the graphics card pushes the frame directly to the monitor without needing to involve the Intel processor at all.
Windows 11 tries to be “smart” about this, but it often guesses wrong for specialized software, putting DAQ software on the dGPU when it shouldn’t. You must take manual control: 1. Open Windows Settings > System > Display > Graphics. 2. Find your DAQ executable in the list, or add it manually. 3. Click Options. 4. To force the iGPU, select Power Saving (which maps to the Intel Arc graphics). To force the dGPU, select High Performance (which maps to the Nvidia/AMD card).
The Rule of Thumb: To achieve the lowest OpenGL latency, always force the OS to render the application using the specific GPU that physically controls the screen you are looking at.
Answer: To determine exactly how your laptop’s HDMI port is physically wired, you need to plug an external monitor into that port and check how Windows and your graphics drivers are routing the signal.
Here are the two most definitive ways to check this in Windows 11.
Windows 11 explicitly tells you which graphics processor is driving a connected screen.
If your laptop has a discrete NVIDIA GPU, the NVIDIA Control Panel has a dedicated hardware map that physically illustrates your port layout.
(Note: If the NVIDIA Control Panel is missing the “Display” or “PhysX” tabs entirely, or if it says you are not currently using a display attached to an NVIDIA GPU, your HDMI port is hardwired to the integrated graphics.)
If you don’t have an NVIDIA GPU or the control panel is acting up, you can watch the hardware telemetry live.
Ctrl + Shift + Esc to open Task
Manager.fin