CME-Messungen für latenzarme HFT-Empfänger

Zusammenfassung

Diese Studie untersucht, wie CME-Marktdatenpakete und Transaktionen der Matching Engine eintreffen, und leitet aus diesen Messungen Gestaltungshinweise für Empfänger im Hochfrequenzhandel ab. Die Ergebnisse beruhen auf Beobachtungen des Frontmonat-Kontrakts Nasdaq-100 E-mini über mehr als ein Jahr. Dazu gehören Börsenzeitstempel für Pakete und Transaktionen sowie ein Abgleich mit einem produktiven Empfänger im Live-Betrieb.

Die Autoren stellen fest, dass die Matching Engine die Transaktionsschübe prägt, während der Datenanbieter ausgehende Pakete in Abständen von etwa 7.5 Mikrosekunden sendet. Verarbeitet ein Empfänger Pakete innerhalb eines solchen Intervalls, entsteht durch die Ankünfte keine Warteschlange; in diesem Fall ist ein einzelner Thread vorzuziehen. Bei längerer Verarbeitungszeit kann der zeitliche Verlauf der Schübe einen langen Nachlauf in der Warteschlange verursachen. Eine Aufteilung der Verarbeitungskette auf zwei Threads kann diesen Nachlauf verringern, wenn dadurch die langsamste Stufe verkürzt wird, erhöht jedoch die Latenz bei der üblichen Verarbeitung. In der Nähe des Sendeintervalls führt die Studie die verbleibende Nachlauflatenz auf Pakete mit mehreren Nachrichten und variable Verarbeitungszeiten zurück. Diese Ergebnisse gelten für den untersuchten Datenstrom und die gemessenen Empfängerbedingungen; sie belegen nicht, dass dieselbe Thread-Aufteilung für jedes System optimal ist.

Kernaussagen

• Die Schübe der Transaktionen der Matching Engine prägen die beobachteten Ankunftsgruppen stärker als die Bündelung von Paketen.
• Ein Empfänger, der Pakete innerhalb des Sendeintervalls verarbeitet, vermeidet im untersuchten Szenario durch Ankünfte bedingte Warteschlangen.
• Eine zweistufige Verarbeitung mit Threads kann Nachläufe in Warteschlangen verringern, wenn sie die Engpassstufe verkürzt.
• Nahe am Sendeintervall sind die Kosten pro Nachricht und variable Verarbeitungszeiten wichtiger als die Anzahl der Threads.

Schlagwörter

# Packets, Transactions and Queues: Design Principles for HFT Systems from a Measurement Study of CME Market Data


# Packets, Transactions and Queues: Design Principles for HFT Systems from a Measurement Study of CME Market Data









HFT systems are conventionally built as a single-threaded event loop, on the rule that every thread hop adds latency. We test that rule against a measurement study of more than a year of CME market data for the NQ front-month contract, following every packet and matching-engine transaction through the feed's two exchange timestamps, and checking the results against a live production receiver. Packets arrive in near-critical self-exciting clusters that belong to the matching engine's transactions, not to how the exchange packs them. The engine often processes consecutive transactions within a fraction of a microsecond, while the market-data publisher sends at most one packet per publisher period of about 7.5 microseconds, so a burst reaches the receiver as a train of packets one period apart. This yields design principles for HFT systems. First, a receiver that handles each packet within one publisher period never queues on arrivals, however bursty the market; there one thread is best. Second, above that period a queueing tail appears, driven by the timing of transactions, not by packet rate or size, and two threads can be better than one: splitting the servicing chain into two stages on separate threads removes most of the tail at the cost of one hop on the median. Third, only the slowest stage matters, so a split pays only if it shortens it. Fourth, just under the period, where the production receiver runs, the remaining tail comes from multi-message packets and variable service times, and the levers are cost per message and spread of service, not thread count. An analytic framework, a burst-limit throughput identity and an exact reduction of the tandem to a single bottleneck server, supports these results.

Vollständig mit Quellenangabe unter der Lizenz der Quelle angezeigt. Lizenz: abstract CC0

Diese Zusammenfassung wurde vom Research-Agenten von Stratmill anhand des Originals verfasst; sie ist keine Kopie der Quelle.