wire_latency.hpp File Reference

Network-thread order latency: what happens to an outbound order after the engine pushed it into the venue's outbound ring. More...

#include "fastmm/core/config_macros.hpp"
#include "fastmm/core/latency.hpp"
#include "fastmm/core/messages.hpp"
#include "fastmm/core/msg_ring.hpp"
#include "fastmm/core/time.hpp"
#include "fastmm/venues/order_commands.hpp"
#include <array>
#include <cstddef>
#include <cstdint>
#include <span>

Go to the source code of this file.

Classes
struct	fastmm::venues::WireLatencyStats
struct	fastmm::venues::WireLatencyWindow
	The three over one window (WireLatencyRecorder::summarize). More...
class	fastmm::venues::WireLatencyRecorder
class	fastmm::venues::BatchedOrders
	The orders a venue encoded into a corked connection. More...
struct	fastmm::venues::BatchedOrders::Entry
class	fastmm::venues::OutboundBatch
	The engine's batch handed over directly (run-to-completion, Venue::send_now) behind the consumer side of MsgRing, so drain_outbound_coalesced takes either. More...

Namespaces
namespace	fastmm
namespace	fastmm::venues

Functions
template<class Ring , class Cork , class OnMessage , class Uncork >
void	fastmm::venues::drain_outbound_coalesced (Ring &ring, WireLatencyRecorder &wire, Cork &&cork, OnMessage &&on_message, Uncork &&uncork)
	Drains the engine's outbound ring (or an OutboundBatch) in batches of at most kMaxBatch messages: cork() holds the connection's writes back, on_message(header) encodes and "sends" each message into the connection's buffer, uncork() writes the batch with one system call and returns false when the connection failed (the venue rejects the batch's orders there, see BatchedOrders).

Detailed Description

Network-thread order latency: what happens to an outbound order after the engine pushed it into the venue's outbound ring.

Per order message the venue takes three rdtscp stamps (before encoding, after encoding, after the WebSocket/REST send call returned) and records

encode JSON encoding and signing send the send call (TLS + WebSocket write, or queueing the REST request) tick_to_trade after-send minus the header's t0_cycles, the network thread's receive stamp of the inbound event that triggered the order (only when t0_cycles != 0)

Histograms are in TSC cycles and owned by the network thread; summarize() converts to ns with a calibration when the venue publishes its status, for the whole session and for the last minute and the last hour (core RecentHistogram), so a recent tail shows under a long session's totals. Recording never allocates.

Coalesced sends (drain_outbound_coalesced): between begin_batch() and end_batch() record() keeps the encode stamps of up to kMaxBatch orders and ignores its after-send stamp, since the send call only queued the bytes; end_batch() records every kept order with the stamp taken after the one write of the batch returned.