Wie viel Latenz solltest du einem Backtest hinzufügen? Wir haben jede Millisekunde unserer Latenz gemessen

Vier Zahlen, alle aus unserem eigenen Paper-Trading-System gemessen: eine Strategie, 1-Minuten-BTCUSDT-Perpetual-Signale, 31 Tage und 1,418 Orders. Medianzeit vom Balkenschluss bis zur Bestätigung der Order durch die Börse: 195 ms. 99. Perzentil: 2,970 ms. Median in den 1% der Minuten mit der höchsten realisierten Volatilität: 840 ms. Und die Latenzkonstante, die während des größten Teils des Vorjahres in der Backtest-Konfiguration stand: 0.

Drei dieser Zahlen sind langweilig. Jeder weiß, dass 0 falsch ist, jeder ersetzt sie irgendwann durch etwas anderes, und dieses Etwas ist fast immer eine Konstante, die jemand nach Gefühl gewählt hat. 100 ms, 250 ms, „gehen wir lieber auf Nummer sicher: 500“. Die Zahl, auf die es wirklich ankommt, ist 840, denn sie zeigt, dass deine Latenz vom Marktzustand abhängt. Und die Marktzustände, in denen sie in die Höhe schießt, sind dieselben, in denen dein Signal glaubt, etwas entdeckt zu haben.

Wofür die 195 Millisekunden draufgehen

Hier ist das vollständige Budget, Stufe für Stufe gemessen, mit Zeitstempeln einer monotonen Uhr an jedem Übergang. Der Server ist eine AWS-Instanz in ap-northeast-1, in derselben Region wie die Endpunkte der Handelsplattform. Viel näher kommt eine Konfiguration für Privatanleger ohne Co-Location kaum.

Zwei Dinge vorweg, bevor es interessant wird. Erstens: Die Mediane addieren sich nicht: 128 + 3 + 11 + 47 = 189, während der gemessene Ende-zu-Ende-Median bei 195 liegt. Perzentile sind nicht additiv. Wenn du deine Latenzschätzung durch Addition der p99-Werte jeder Stufe erstellst, kommst du auf 3,128 ms, obwohl das tatsächliche p99 bei 2,970 liegt. Hier nah genug dran, aber völlig daneben, wenn die Stufen in die andere Richtung korreliert sind. Miss den gesamten Ablauf.

Zweitens: Schau dir die oberste Zeile an. Zwei Drittel des Medianbudgets entfallen darauf, darauf zu warten, dass die Börse den Balkenschluss meldet. Nicht auf das Netzwerk, nicht auf deinen Code, nicht auf die Orderweiterleitung. Die Handelsplattform fasst Trades zu einer Kline zusammen, entscheidet, dass die Minute vorbei ist, und sendet das Ereignis. Davor liegt eine Warteschlange, die alle anderen Abonnenten dieses Streams mitbenutzen.

Die 840

Wenn man jede dieser 1,418 Orders nach der realisierten Volatilität der Signalminute gruppiert, ergibt sich ein ganz anderes Bild.

Jede Stufe wird gleichzeitig langsamer, wodurch sich der Effekt verstärkt. Die Aggregations- und Broadcast-Warteschlange der Handelsplattform wird durch die Auslastung der Matching-Engine beeinflusst. Deshalb wird eine Minute mit 11,000 Trades später übertragen als eine mit 600. Dein eigener Prozess verarbeitet im selben Zeitfenster mehr Aktualisierungen der Markttiefe und mehr Trade-Meldungen. Das Feature-Update, das normalerweise 3 ms dauert, braucht dann 28. Der REST-Orderpfad konkurriert mit den Panikorders aller anderen, und gelegentlich bekommst du einen 503-Fehler mit erneutem Versuch, der für sich allein eine volle Sekunde kostet. Der Korrelationskoeffizient zwischen der Trade-Anzahl im Signalbalken und der Ende-zu-Ende-Latenz lag in unserer Stichprobe bei 0.41. Nicht riesig. Aber genug, um eine Konstante zunichtezumachen.

Die Strategien, die eine erste Prüfung bestehen, handeln überwiegend Ausbrüche, Umkehrbewegungen, Marktverwerfungen und Liquidationskaskaden. Sie werden genau in dem Bereich ausgelöst, in dem die Latenz am schlechtesten ist. Ein Momentum-Signal, das erst bei einer Bewegung von 40 bps innerhalb einer Minute auslöst, ist strukturell so angelegt, dass es immer von der langsamsten Version deines Systems bedient wird.

Einmal haben wir einen Tag damit verbracht, einem Ausreißer von 3.6 Sekunden nachzugehen, der ungefähr jede Nacht zur selben Zeit auftrat. Die Ursache war logrotate: Es kopierte eine 2-GB-Datei und kürzte sie dabei auf demselben EBS-Volume, auf das der Prozess schrieb, wodurch die Event Loop blockiert wurde. Der Markt war unschuldig. Erst messen, dann der Marktstruktur die Schuld geben.

Was das für deine Ausführung bedeutet

Während du wartest, bewegt sich der Preis. In einer zufälligen Minute betrug die durchschnittliche nachteilige Kursbewegung während unseres Medianwerts von 195 ms etwa 1.1 bps entgegen der Signalrichtung. In den Minuten des obersten Quartils waren es bei 312 ms 5.8 bps. In den Minuten der obersten 1% waren es bei 840 ms etwa 14 bps nachteilige Bewegung, bevor die Order überhaupt das Orderbuch erreicht.

Bei BTC-Perpetuals spielt der Spread dabei kaum eine Rolle: Ein Tick bei einem Kurs von 84,000 entspricht 0.012 bps. Der Schaden entsteht also durch die nachteilige Kursbewegung, nicht durch die Kosten des Spread-Überquerens. Verschiebst du dieselbe Strategie auf einen Perpetual mit mittlerer Marktkapitalisierung, kommt der zweite Faktor ins Spiel: Der Geld-Brief-Spread an der Spitze des Orderbuchs stieg in unserer Stichprobe von 1.4 bps in ruhigen Minuten auf 6.2 bps im obersten Quartil, während die verfügbare Tiefe an diesem Kurs um mehr als die Hälfte sank. Du bezahlst gleichzeitig für die Kursbewegung, den breiteren Spread und die geringere Tiefe, weil all das dieselbe Ursache hat.

Als wir dieselben 31 Tage mit bedingter Latenz pro Balken statt mit pauschal 200 ms erneut abspielten, verschlechterte sich der durchschnittliche Einstiegskurs im Backtest um 3.1 bps. Das betraf fast ausschließlich 9% der Trades. Die Abweichung zwischen Einstiegskursen im Backtest und im Paper-Trading sank von 4.2 bps auf 0.9 bps. Der In-Sample-Sharpe dieser Strategie fiel von 1.7 auf 1.1. Das ist die ehrliche Zahl, und das war sie schon immer.

Was gehört also tatsächlich in die Konfiguration

Kein Einzelwert. So machen wir es jetzt:

1. Stichprobe statt Festwert. Ziehe die Latenz jeder simulierten Order aus einer empirischen Verteilung, die von der Aktivität des jeweiligen Balkens abhängt. Trade-Anzahl und absolute Rendite reichen aus; beides ist bereits in einer standardmäßigen Kline enthalten. Passe die Verteilung einmal pro Handelsplattform und Ordertyp an und berechne sie monatlich neu.
2. Den Randbereich beibehalten. Passe keine Lognormalverteilung an und erkläre die Sache damit für erledigt. Das p99 steckt in Wiederholungswellen und GC-Pausen, die keine glatte Verteilung abbildet. Wir verwenden empirische Quantile und ziehen den Randbereich oberhalb von p95 erneut aus der Stichprobe.
3. Latenz gilt auch für Stornierungen. Auch ein Stop-Ersatz oder das Stornieren einer Hedge-Order unterliegt derselben Verzögerung. In schnellen Märkten konkurriert deine Stornierung mit einer Ausführung. Wenn dein Simulator sofort storniert, ist dein Risikomodell Fiktion.
4. Eine Aktualitätsgrenze einbauen und simulieren. Unser System verwirft jedes Signal, dessen Balken bei Ankunft älter als 1.5 Sekunden ist. Dieses Verhalten ist real und hat reale Kosten: Es entfernt unbemerkt Trades. Im Backtest müssen dieselben Trades wegfallen.
5. An Paper-Trading-Daten neu kalibrieren. Im Paper-Trading bekommst du die tatsächlichen Referenzwerte. Protokolliere bei jeder Order die Zeitstempel aller vier Übergänge und vergleiche wöchentlich die Verteilungen mit den Annahmen des Simulators.

Der grundsätzliche Fehler besteht darin, einen Ausführungsparameter als unabhängige Konstante zu behandeln, obwohl er vom selben Zustandsfaktor abhängt wie dein Signal. Gebühren verhalten sich berechenbar, Funding verhält sich berechenbar, Latenz nicht. Wenn du dir aus all dem nur eine Zahl merken willst, dann das Verhältnis: Unser p99 ist fünfzehnmal so hoch wie unser Median, und unsere Signale treffen überproportional oft nahe dem p99 ein.

Instrumentiere die vier Übergänge. Das kostet einen Nachmittag und verrät dir mehr über deine Strategie als eine weitere Woche Parametersuche.