Quants worth following: David Lariviere, part 1

"Quants worth following" is our interview series highlighting thought leaders in the quantitative trading industry who actively share their knowledge and resources with the community.

This edition features Professor David Lariviere, a Clinical (Full) Professor at the University of Illinois at Urbana-Champaign and the Founder and Director of the University’s FinTech Lab (FTL). David has a rare blend of experience in programming, performance engineering, artificial intelligence, networking, custom hardware, signal processing, databases, and industrial and enterprise systems engineering — expertise he has applied to ultra-low latency trading, market microstructure research, exchange infrastructure, cybersecurity, and teaching. At Illinois, he has trained quants, developers, data analysts, and students from over two dozen different majors across the university.

David’s career spans executive director, consulting, and C-suite roles, as well as advisory boards for startups and leadership positions at firms including GTS and CME Group. His work in performance engineering and public education has influenced the broader industry, and he holds multiple patents deployed in production to safeguard financial systems processing over a quadrillion dollars in notional value each year. He has been quoted in outlets such as The Wall Street Journal and Financial Times. In 2025, he was inducted into the STAC Research Fellows, recognizing him as one of the world’s leading experts on optimizing and benchmarking high-performance systems. He is also a member of the FBI’s InfraGard, a public-private partnership “dedicated to protecting U.S. critical infrastructure and the American people.”

David was first introduced to computers through his family’s DOS-based Intel 80286, equipped with a 20MB hard drive and a 2400-baud modem that connected to the Prodigy online service. At the same time, Bill Gates had become the world’s youngest billionaire, inspiring many—including David—to pursue computing and software development.

David began coding at the age of eight, starting with QBasic before quickly moving on to C and C++ in the early 1990s, teaching himself using books from the local library. In 1995, the film Hackers was released, portraying teenage computer whizzes who used their skills to both disrupt and defend society. The movie opens in a courtroom, where a prosecutor describes the exploits of 11-year-old “Zero Cool”:

“Dade Murphy, who calls himself ‘Zero Cool,’ has repeatedly committed criminal acts of a malicious nature. This defendant possesses a superior intelligence which he uses to a destructive and antisocial end. His computer virus crashed 1,507 systems, including Wall Street trading systems, single-handedly causing a seven-point drop in the New York Stock Market.”

Convicted, Dade is barred from using a computer or phone until his 18th birthday. The scene—and the film as a whole—left David with a lasting impression: both the fascination and the responsibility that come with the power and knowledge of computing, a lesson he’s carried ever since.

At 14, in 1999, David began building Davidia, a home automation assistant reminiscent of today’s Alexa. He combined CGI-based websites, MFC C++ GUIs, SAPI voice recognition, and PDAs to control lights, fans, TV tuners, music, and even AOL away messages. It also gave him his first hands-on exposure to embedded systems, where he learned to write device drivers.

At 18, David followed Dade’s path and moved to New York City to study Computer Science at Columbia University, where he earned both a B.S. and M.S. with a focus on AI and computer vision. By his junior year, he was carrying a 1.5x graduate-level course load while also consulting in the industry, often working through the night; he later served as a teaching assistant for graduate courses in Embedded Systems and Computational Robotics and explored computer architecture, compilers, and FPGA programming—early groundwork for his later interest in ultra-low-latency AI systems, which emerged in the aftermath of 9/11.

While at Columbia, David began his lifelong consulting career, starting in 2005 with BrainMedia, a Manhattan-based audio codec startup that focused on early mobile music streaming—years before the iPhone was introduced. There, he gained hands-on expertise in networking, DSP, edge computing, databases, and optimization of real-time applications on resource-constrained devices. “If the code wasn’t fast enough, the music would literally stop,” he recalls. He reverse-engineered mobile audio systems, rewrote FFTs and MDCTs in Java, C++, and ARM assembly, and eventually led the company’s first Skunk Works team, reporting directly to the CEO, developing prototypes such as early streaming video technology before the smartphone era arrived.

After graduation, David took on a stint building greenfield telco systems. In 2009, he built AI to automatically parse massive binary hardware specifications, generating optimized SQL schemas and loaders for cellular base station records. Manually tuning queries for performance gave him a foundation in three areas that would later prove essential in ultra-low-latency algorithmic trading: systems-level optimization, real-time data handling, and reverse engineering.

Summary

From coding in QBasic at the age of eight to building a home automation system before the concept of smart homes existed, David’s path has always blended curiosity with technical depth. At Columbia, he delved deep into the bleeding edge of AI, computer vision, and embedded systems while also consulting in industry. His early work at BrainMedia on mobile streaming and later telco projects in AI-driven data parsing gave him hands-on experience in systems optimization, real-time data, and reverse engineering—skills that became the foundation for his future work in ultra-low-latency trading.

After several consulting projects and a startup venture, David began his HFT career in 2011 at GTS—a small prop shop in midtown that would later grow into one of only three designated market makers (DMMs) on the NYSE.

David returned to New York as the financial industry was being reshaped by the rise of algorithmic and low-latency proprietary trading firms in the wake of the Global Financial Crisis that had nearly toppled Wall Street.

“It was a golden time and a rebirth of how financial markets functioned. I had a front-row seat to the shift in market structure—sitting just ten feet from the CEO and working alongside former managing directors from across the Street.”

In parallel with his industry work, David also reconnected with his alma mater. He returned to Columbia first as a volunteer and later as an adjunct assistant professor in computer science and electrical engineering. There, he co-taught the Embedded Systems course he had once TA’d, focused on FPGAs and hardware/software co-design, building custom hardware accelerators for a range of applications. It was a full-circle moment—teaching alongside his mentor, Professor Stephen Edwards, who had first sparked his interest in FPGAs at a faculty research exhibition during his freshman year.

Meanwhile, the regulatory landscape was shifting. In 2010, the Dodd-Frank Act and the Volcker Rule pushed proprietary trading out of investment banks and into leaner, faster-moving firms. Initially hired as a senior software developer, David was soon assigned to both CME futures trading strategies and the underlying infrastructure, as well as exchange connectivity. He quickly took ownership of the firm’s CME futures codebase while also leading firmwide infrastructure projects.

At the same time, through its subsidiary Strike Wireless, the firm even built and leased out one of the now-famous microwave links connecting Illinois and New Jersey, in a partnership involving both CME and Nasdaq. The speed and efficiency of a prop trading firm was, at times, astounding; even a single engineer, operating in a corner office in midtown, could build a transcontinental microwave wireless network connecting two of the most important financial exchanges on earth. This was the new face of Wall Street.

Along the way, David dove into exchange connectivity—FIX, MDP, ITCH, OUCH, and other protocols—and applied his backgrounds in low-level profiling, code optimization, quantitative analysis, and networking:

“I rewrote our CME market data decoders, making them about 20x faster — that caught a lot of attention.”

His work extended well beyond just strategy code. At just 27, David was asked to form the firm’s first dedicated software optimization team, followed a year later by another group focused on FPGA-based custom hardware. He became Head of Advanced Technologies, reporting directly to the three founding partners and responsible for evaluating, testing, and deploying all emerging technologies to ensure the firm maintained its competitive edge. Where technology wasn’t yet commercially available, it would be built in-house. Once again, David found himself leading another Skunk Works.

This unit built the firm’s first isolated, automated performance test lab that mimicked production environments, and created large passive tap–based data warehouses to correlate packets, market data, private order entry, and signals research. It also developed advanced market data and latency monitoring systems. The team migrated from software-based logging and NTP timestamping to FPGA-enabled passive tap capture solutions with GPS-synced pulse-per-second (PPS) timestamping, supported by a RAM-based database for correlating packets, events, trades, and countless KPIs at the exchange gateway and matching engine level. David fondly recalls driving to Carteret, NJ, to install their FPGA-based custom hardware strategies in Nasdaq’s data center—shattering previous latency records.

“At a small prop shop, one person might do the work of five or ten teams (each of up to five people) at a big firm. It was an enormous and very educational opportunity, though also quite stressful.”

In addition to advanced technologies, David also led the firm’s interdesk CME trading strategy research initiative, internally called the “Globex Group.” This was a collection of competing desks that agreed to pool research and analysis on one of the world’s most important futures exchanges. As the Globex Group ramped up trading, GTS’s share of the futures market surged; by 2014, the firm was handling between 5–10% of rate futures.

“Students often ask me what motivated me to go into HFT. I tell them it’s like the Olympics — but for computer scientists and electrical engineers. Except here, the race isn’t every four years; it’s every single second of every day. Some of the world’s greatest scientists, mathematicians, and engineers continually innovate and compete to build the fastest solutions on earth. The moment you’re no longer the fastest, you immediately know — you’re ticked out on the tape. The goal of modern automated electronic markets is to simultaneously receive, distribute, understand, and react to the cumulative current state of all of humanity’s knowledge — instantly, constantly, everywhere, and in real time."

Summary

David entered HFT in 2011 at GTS, a small prop shop that would later become one of the NYSE’s three DMMs. At GTS, he spanned CME futures algorithm development, exchange connectivity, and advanced performance engineering—leading projects from 20x decoder optimizations to FPGA-based trading systems and latency monitoring infrastructure. By 2014, he was also directing the firm’s collaborative “Globex Group,” which helped GTS capture 5–10% of rate futures.

From his desk, David had a front-row seat to several high-profile, technology-driven market meltdowns in 2012 and 2013, a mere subset including:

• Facebook IPO on Nasdaq
• BATS IPO on its own exchange
• Knightmare on Wall Street at Knight Capital, where a failed software upgrade triggered losses of about $400 million in under an hour
• Associated Press Twitter account hack, which briefly sparked a stock market flash crash
• Eurex time-synchronization glitch
• CBOE Options Exchange open failure
• Nasdaq SIP halt, which stopped trading in all Tape C symbols
• Goldman Sachs options trading glitch

These incidents left an indelible mark on David and underscored the absolute necessity of fault-tolerant, “can NOT fail” engineering, testing, and continuous monitoring of the most critical systems and exchanges in the world.

As David emphasizes, elite technologists may achieve mind-blowing optimizations and latency reductions, but never at the expense of reliability or stability.

Before building a dedicated optimization team, David says the first step is simple: know what you’re optimizing—and whether it will actually move the needle.

“You can spend $50 million building a custom ASIC—and still lose to a signal from a market you’re not even watching. Maybe it’s a venue your strategy ignores. Maybe it’s a quirk in the exchange’s tech stack your traders don’t even know exists.”

David recalled measuring orders over the same fiber, where a packet sent 50,000 nanoseconds later still arrived first at the matching engine—a sobering reminder that the race isn’t always about shaving nanoseconds off “tick-to-trade.”

As reported by Alexander Osipovich in the Wall Street Journal, traders on a major exchange sometimes received private fill notifications before the public data feed updated. Supporters argued this encouraged firms to add liquidity, while critics favored exchange models that release public data first.

“You could reduce public market data latency from 2,000 nanoseconds down to 2 nanoseconds using cutting-edge hardware. But you’re still not guaranteed to win if you’re competing against someone writing simple C++ code, running entirely in software, but still leveraging those much earlier private fills.”

For futures traders, one of the biggest architectural choices—often dictated by a firm’s size and market presence—is whether private fill information remains desk-specific or is shared firm-wide through a ticker plant. Equally important is the decision to take losses on one exchange to recover them on another, a calculation shaped by both volume and fee structures.

“It’s not just about being the fastest or knowing the quirks. You need to understand market dynamics, and you have to be a certain size to compete statistically.”

Siloing optimization from research often leads teams astray. Technologists chase speed when signals matter more, while quants chase signals when technology is decisive. The real edge comes from unifying both within a single team.

As firms scale, knowledge sharing becomes harder. Responsibilities are split across teams—networking, packet capture, decoding, order entry, risk, market data—while each layer of specialization adds latency and obscures cross-stack insights. As The Mythical Man-Month noted, adding people doesn’t guarantee productivity; in low-latency trading, each silo compounds the problem, often nonlinearly.

“One of the single greatest challenges of working in this highly secretive space is knowing what secrets not to share but also which ones you must to be successful.”

Sometimes the edge comes from having a single engineer with end-to-end ownership—full access to the fiber optic cables, visibility of all infrastructure, and model logic. With that also comes complete accountability for every photon moving through it. These are the firms that win the speed trades. By contrast, bureaucratic shops with half a dozen teams pipelined between the strategy logic and the fiber optic cable often fall behind, as solutions are lost in finger-pointing, while the C-suite grapples to understand why.

Sometimes optimizing the latency in a hardware pipeline is very similar to optimizing performance within a trading firm itself, collapsing multiple separate stages of abstraction into a single highly specialized functional unit with full visibility and complete control.

Summary

David warns that optimization only matters if you’re tuning the right component. Firms can spend millions on hardware and still lose to overlooked signals or exchange quirks. The edge, he says, comes from uniting research with engineering and giving people true end-to-end ownership.

Gateway arbitrage was a well-known issue across electronic markets—not just on CME, but on nearly every exchange and asset class. Former HFT technologist Jacob Loveless even detailed it in his paper, “Barbarians at the Gateways: High-Frequency Trading and Exchange Technology.” In one example, he describes how arbitrage can play out:

“A is connected to two distinct gateways. In 11b, Client A induces extreme load on Gateway 1, causing Client B's traffic to slow. In 11c, Gateway 1, not under load, slows all attempts for Client B to cancel resting markets. Client A has an advantage with the self-made fast path.”

While overseeing GTS’ CME trading infrastructure, David built analytics and reporting tools, dissected packet timestamps, and reverse-engineered CME’s architecture to measure performance across the trading day. He grew frustrated that slower orders often reached the market first, complicating the operation of trading strategies—including market-making designed to improve prices globally.

CME’s response was simple: “Come help us fix it.”

At 29, CME offered David an executive director role to form a small, dedicated optimization unit, leading both software and hardware optimization, and to oversee the rollout of a new architecture, the Market Segment Gateway (MSGW). The MSGW was designed to address the very issues David and other firms had long pressed CME to fix. Once again, he turned to academia, recruiting and training a team of student engineers who moved with him to Chicago to build the new group.

When David was trading on CME, the exchange operated 56 separate “gateways”—the machines and software that received messages from traders, validated orders, and forwarded them to the appropriate matching engine or “market segment” to either execute immediately or rest on the order book.

CME’s proposal was bold: to improve fairness, the exchange would supplant its 56 separate gateways—like lanes on a highway, each with its own speed and backlog—with a single gateway per market segment. Every message for a specific market would enter through that gateway, where the 10Gbps network interface card (NIC) would hardware-timestamp packets and guarantee the first arrival executed first in the matching engine. It was a direct answer to the concerns David and many other traders had raised while building strategies, both on CME and every other exchange.

The stakes were enormous. CME is the leading U.S. futures exchange, with contracts that influence U.S. equities, energy, metals, agriculture, interest rates, and even government debt. “I often teach my students: virtually every major input into modern living in some way is determined, hedged, and insured by products that trade on CME. It essentially prices and protects the cost and risk of life on earth for everyone alive today.”

Working on the project was both exciting and daunting. David spent long nights and early mornings monitoring log files, latency distributions, packet errors, passive taps—any signal of a current or potential problem. He had access to every packet flowing through Globex, a rare privilege he was careful never to misuse. As a former trading technologist, he brought a deeper understanding than most exchange engineers of what he was seeing, what might become an issue, and how best to safeguard the system during rollout of the new architecture. He even built custom hardware to blast wire-rate FIX traffic, replicating the real-world scenarios customers would generate once connected.

“I often joke that the MSGW project took three years of my life and ten years off my life. The funny part of the joke is that I’m probably not joking.”

At CME, David experienced firsthand the contrast between a small prop firm and a Fortune 500 company. He was struck by the cohesion and professionalism of his colleagues, and by the exchange’s well-oiled operations—best practices refined over decades of electronic trading.

Every Saturday morning for months, hundreds of employees arrived at CME’s headquarters at 20 South Wacker to swap the existing market infrastructure for the new MSGW stack, testing and benchmarking it in production. Customers were invited and encouraged to send mock orders to surface potential issues before the system went live. Testing could only happen on Saturdays, as CME’s markets run 23 hours a day—from Sunday night to Friday night. Given the critical importance of its products, traders worldwide rely on CME to manage risk and protect portfolios in response to global events. Its slogan is neither an accident nor an exaggeration:

“CME: Where the world comes to manage risk.”

In 2016, the MSGW went live—a project later deemed a resounding success, the culmination of efforts from thousands of people worldwide. David’s contribution was one very small part of a much larger collective effort, and customers welcomed the new model; before long, other exchanges, including Eurex and CBOE, adopted the same technology stack, ushering in a new era of fairness in electronic markets.

Had the project failed, it would have made front-page news in the financial press. Because it succeeded, it barely registered in the public domain. The most important work is often the least glamorous. To those whom David had the privilege of working with, it was an enormous honor that he will remember for life.

As the project wound down in late 2017, and perhaps partly from the physical stress, David ruptured his Achilles tendon, which led to other injuries after countless long nights. He decided to step back from consulting and focused on teaching at the University of Illinois while recovering.

Summary

David joined CME at a pivotal moment to help design and launch the Market Segment Gateway (MSGW), a new architecture created to address long-standing fairness issues in electronic markets. Leading a small optimization team, he oversaw software and hardware engineering, testing, and rollout of a system that replaced 56 gateways with a unified, timestamped model. The stakes were enormous—CME’s futures underpin global markets—but the launch in 2016 was a success. Customers welcomed the change, competitors followed, and the project quietly reshaped electronic trading before David stepped back to recover from injuries and focus on teaching.

Before rushing to optimize, David advises asking three questions:

1. Will it make a difference?
2. Should I be faster or smarter?
3. What’s the potential PnL—and at what cost?

Many trading firms begin their optimization journey by measuring time in software—tracking when their code first sees a signal and how long it takes to trigger a buy or sell. But software timing can slow the code itself and often underestimates latency. Packets can sit unnoticed in a NIC or TCP stack buffer for millions of nanoseconds before the software even registers them. As anyone who’s slept through an alarm knows, there’s a big difference between when it rings and when you wake up. For this reason, the most sophisticated traders turn to custom hardware rather than commodity software.

That’s why David emphasizes precise external instrumentation—using fiber-optic passive taps and GNSS-based time synchronization—before deciding where to optimize. Traders often believe they’re much faster on the wire than they actually are. It’s also why his FinTech Lab is filled with GPS receivers and antennas, an atomic clock, clock-distribution boards, fiber optic passive taps, and cutting-edge FPGAs—tools of the trade for measuring true performance.

“Traders often say, ‘We need it faster.’ But faster what? Sometimes it’s only one rare event—like a market open or a ‘magic packet’—that actually matters. Without that clarity, developers waste effort chasing the wrong problems.”

Some of the questions he uses to guide this process:

• How much infrastructure can you realistically and safely optimize?
• Are developers embedded with traders or kept in silos?
• Who holds the complete set of optimization skills?
• How do you balance focus and breadth?

He cautions that even external latency measurements can be misleading without the right tools and reference points. You might say you know your latency on the wire—but which wire, and at what point are you measuring it?

At Eurex, for example, the High Precision Time (HPT) service shows, to the nanosecond, when every customer’s order (anonymized) first hits the exchange’s network—exposing simultaneous submissions that are invisible in most other real-time market data. By contrast, the vast majority of exchanges record hardware timestamps only after orders have already been serialized through layers of infrastructure—switch ports, routers, gateways, and matching engines.

Worse, many quants don’t realize that even nanosecond timestamps from a matching engine or gateway are only approximations—and can fall short of the precision truly needed to win the speed race.

Beyond quants and technologists, especially at large firms, compliance efforts can further damage latency and introduce institutional financial risk. Well-intentioned cybersecurity teams may apply standard practices across all machines, insisting on scans of production trading systems or routing packets over network paths that should remain pristine. Even something as simple as scanning a log file or SSH-ing into a trading machine, if not carefully tuned, can degrade or disrupt performance—putting the firm’s “best execution” obligations at risk.

To make matters worse, most exchanges don’t even offer raw packet capture files (PCAPs) with network-level timestamps of outbound market data. Even when they do, there’s no guarantee the timestamps reflect what end customers actually see when the first photons of a market data event arrive. And because each exchange timestamps and captures packets differently, uniformity across markets is nearly impossible.

“That gap is what led me to Databento’s PCAP offerings. After a decade without access, I finally have uniform cross-exchange PCAPs again—and I’m now incorporating them into my courses.”

Given all this complexity, variability, and uncertainty, three rules apply:

1. Confirm that speed actually matters before investing in it (and recognize it may not be possible in some markets).
2. Measure latency precisely—don’t rely on assumptions or approximations.
3. Instrument and monitor everything: latency, interpacket gaps, packet counters, BIOS messages, temperatures, fan speeds, disk counters, power consumption, CPU core frequency, BIOS settings, rack position, and even real-time terrestrial and space-based weather.

Summary

Too many firms chase speed without knowing what they’re really measuring. Software timing, exchange timestamps, and even compliance controls can all create blind spots—or worse, add latency. David’s approach focuses on precise external instrumentation, custom hardware, and cross-exchange PCAPs to reveal what’s truly happening on the wire. His rule of thumb: know when speed matters, measure it correctly, and monitor everything.

Even once you’ve confirmed speed matters, David warns that not all latency gains are equal—and some optimizations border on the absurd—or at least seem to at first.

One example comes from academia: David recalled a Ph.D. student introducing him to the work of Professor Keren Bergman at Columbia’s Lightwave Research Laboratory, which explores silicon photonics and pure photonic networking. There, David first encountered the idea of processing packets entirely in light—without converting to electricity and back—an absolute dream for any low-latency trader.

“The optimal way to optimize a component is to remove it entirely from the latency pipeline.”

David sees enormous promise in this field, not only for trading but also for AI data centers, where it could boost performance while reducing power consumption and cooling demands.

Many “standard” industry tricks—kernel bypass, custom TCP/IP stacks, tickless kernels, IRQ steering, thread core pinning, custom memory allocation, NUMA tuning—are well known in HFT. The real edge often comes from exploiting microstructure quirks and lesser-known engineering hacks.

One trading-specific optimization is the “TCP gap” trick, described in several public patents. A trader preloads a stream of order messages into a TCP session’s receive buffer inside the exchange gateway’s TCP stack, leaving a small gap at the front so they can’t be ingested by user-mode code. When ready, the trader sends a single minimum-sized Ethernet frame to plug the gap, instantly releasing the entire batch of orders into the gateway. The effect is like faxing pages two through ten thousand first—none are delivered until the first page finally arrives.

Another, more amusing potential trick—similar to what gamers sometimes attempt with CPUs—is overclocking Ethernet links. Because the IEEE allows a margin of error in clock rates, it’s possible to send data slightly faster than the nominal 10.3125 Gbps, if the receiver’s hardware can tolerate it. Even simpler, switching from standard silica fiber to hollow-core fiber can yield significant latency improvements.

Regulatory disclaimer: David did neither of these while at GTS; however, both were among the many optimizations disclosed in patents he co-authored during the MSGW project (see CME’s “iLink architecture” for background on the MSGW gateway model). One of those patents would later earn him a small place in Donald MacKenzie’s “Trading at the Speed of Light: How Ultrafast Algorithms Are Transforming Financial Markets” (p. 168).

Beyond order entry, feed asymmetry and variability are another underappreciated factor. For years, many assumed the “A” feed was always faster than the “B” feed—until an exchange changed its architecture and locations, costing firms precious microseconds if they failed to catch the change in real-time or even in backtests. With exchanges offering multiple feeds of different granularities (trades, top-of-book, depth, market-by-order, drop copy), no single source can be assumed to be the fastest 100% of the time.

“If you want to be among the elite firms, you have to do all the basics—and then a whole lot more. But you also have to know when you’re barking up the wrong tree entirely.” One pitfall of siloed optimization teams is that, disconnected from strategy logic or actual low-latency triggers, they may not know which “tree” matters—or when to stop barking and start whistling.

Other bleeding-edge techniques include not just FPGAs but also custom ASICs, layer-one switches, and N-way passive taps. Even the location of a rack in a data center—or the height of an antenna on a roof or tower—can shift performance when every nanosecond or even picosecond counts. More recently, another exchange was in the crosshairs for allegedly offering hollow-core fibers, with dramatically lower latency, to only a subset of customers and leaving it completely unadvertised.

In optimizing latency between data centers and financial centers, some firms have even experimented with low-earth satellites or century-old shortwave radio to shave transoceanic latency.

“I even get NOAA space-weather alerts on my phone now, because ionospheric conditions can affect both GPS and transcontinental latency of shortwave radio…”

Some in this space have even joked for years about using neutrinos to tunnel straight through the Earth’s crust, bypassing its curvature entirely. That idea became even more amusing when the University of Chicago and Fermilab received an anonymous $5 million gift for neutrino research, with Fermilab just steps away from the world’s most important exchange data center.

The ultimate latency reduction would be to move information faster than the speed of light—a physical limit set by Einstein that has defined the boundaries of trading ever since. For a moment, CERN even suggested it might have been broken, before the result was traced to something more familiar to HFT technologists than physicists: a loose GPS cable.

“If trading firms ever start experimenting with wormholes between datacenters and continents, let’s hope they have the proper safeguards in place. On the bright side, if they succeed, the commute in Chicago will also get shorter — regardless of I-90 construction.”

Summary

Not all latency gains are equal. Beyond the usual playbook (kernel bypass, NUMA tuning), edge often comes from microstructure quirks and unconventional engineering—from photonic paths that remove electrical hops entirely to tricks like TCP gaps, hollow-core fiber, and meticulous feed selection. The lesson: pair creativity with measurement, avoid siloed optimization, and remember that placement (racks, antennas, links) can move nanoseconds. And while some ideas flirt with the absurd—even CERN’s brief FTL scare turned out to be a loose GPS cable—the boundary conditions still matter; speed wins only when it’s aimed at the right problem.

For firms still in the latency race, David notes the answer depends heavily on the exchange—its architecture, design choices, and variability. At the extreme end of fairness, exchanges struggle to distinguish which packet truly arrived “first,” given differences as small as cable lengths or PCB traces across switch ports. “Firms can optimize more than exchanges can actually tell the difference,” David warns.

The focus on fairness has become so intense that one exchange offered equidistant armored fiber cables within a single rack—so whether a server was mounted at the top or bottom, latency was identical. The armor was presumably to prevent traders from trying to shave them down. A competing venue instead re-normalized its fiber optic cable lengths, ensuring deviations no greater than “±0.35m.”

Vendors have also begun chasing picoseconds (ps). One recently announced outbound multicast synchronization across switch ports to “within 50 ps”; another can now timestamp packets to ±75 ps. But if packet arrivals differ by even a fraction of that tolerance, the larger question looms: can firms still make it faster—or will it no longer matter once the exchange attempts to order it?

“Exchanges, generally, continue to equalize to achieve fairness in their markets. Yet this effort has become a seemingly never-ending and expensive race. Once ‘equalized’ within one margin, trading firms and their latency optimization teams push further, demanding even tighter fairness and testing the limits of engineering — from micros to nanos to picos and beyond. At some point, we as an industry need to move past the delusion of 'FIFO' and acknowledge that exchanges can no longer determine which order actually arrived first to the nanosecond, picosecond, or femtosecond. Once we reach this collective realization, we can then fundamentally change how exchanges fairly match and price orders. That time may finally be approaching, and when it does, we will no longer optimize purely for speed but for competitive real-time intelligence — competing to offer even better prices to the markets and to society as a whole.”

The answer depends on how—and where—the know-how is applied. At CME, the goal was to protect one of the world’s most critical exchanges. At the University of Illinois, it meant training the next generation of quants through MSFE practicum projects sponsored by various financial firms. After an injury in late 2017, David shifted more toward academia, focusing on how low-latency engineering principles could benefit domains far beyond finance.

“One of the reasons I teach is to look for other areas, other problems of society—completely unrelated to finance—that can benefit from what we’ve already developed and are extremely good at.”

David has also become more involved with STAC Research, collaborating with industry on evaluating and benchmarking financial technology across the stack. He now serves as co-chair of the STAC FPGA SIG and as the newly appointed chair of the STAC Cloud SIG. As major exchanges — such as CME with Google Cloud, and Nasdaq with AWS — migrate into the cloud, these ecosystems and hyperscalers will play an increasingly important role in the functioning, performance, and safety of the global financial system.

In recent years, David’s attention has turned back to AI optimization, the field where he first began two decades ago. He also points to broader applications of fintech expertise: improving GPS reliability, cutting latency and power use in AI data centers, and designing more efficient network protocols and firewalls. Even niche HFT skills — precision timestamping, signal processing, handling massive real-time datasets — translate into fields such as cybersecurity, aerospace, medicine, robotics, and the protection of critical infrastructure.

“To whom much is given, much more will be asked. To whom instantaneous massively parallel data processing and intelligence is given… well… we will just have to wait and see.”

Summary

Pushing latency further has limits. At the exchange level, fairness measures are already so tight that differences of cable length or PCB traces can decide which packet arrives “first.” Vendors now sell timestamping in the tens of picoseconds, but David warns firms may already be optimizing beyond what exchanges can meaningfully measure. For him, the bigger question is where those skills get applied. From CME to the classroom, he’s focused on redirecting low-latency know-how toward broader impact—whether in AI optimization, GPS reliability, or protecting other critical infrastructure.

In Part 2, David shares how these lessons are shaping his work in academia, from building one of the world's most advanced academic trading labs to preparing students for careers at the intersection of trading, technology, and AI.

Watch the full interview on YouTube, or explore more insights from other Quants worth following in our full series.