GRO/LRO Receive-Aggregation Burst Slippage Playbook
Why this exists
In low-latency execution stacks, market-data quality is usually monitored via packet loss, median feed delay, and CPU usage.
Yet many desks still leak p95/p99 implementation shortfall because of receive-side packet aggregation:
- GRO/LRO merges packets into larger batches,
- user space receives data in bursty clumps instead of near-wire cadence,
- microstructure state is observed with uneven freshness,
- decision/dispatch cadence phase-locks to synthetic bursts,
- queue-priority and short-horizon markout degrade.
This is a hidden infra tax: not pure market regime, not pure model error.
Failure mechanism (NIC/kernel -> execution)
- RX path coalescing/aggregation (GRO/LRO + interrupt moderation) increases packet batch size.
- Event delivery becomes bursty: long quiet gaps followed by dense message clusters.
- Book features (microprice, imbalance, refill) are computed on lumpy timestamps.
- Child-order logic overreacts to burst windows and underreacts during silent windows.
- Passive orders age out of favorable queue slots; aggressive catch-up flow increases.
Result: tail slippage inflation with deceptively stable averages.
Slippage decomposition with aggregation term
For parent order (i):
[ IS_i = C_{impact} + C_{timing} + C_{routing} + C_{rx-agg} ]
Where:
[ C_{rx-agg} = C_{stale-book} + C_{burst-dispatch} + C_{queue-decay} ]
- (C_{stale-book}): decisions on unevenly aged microstructure snapshots
- (C_{burst-dispatch}): child-order bunching caused by burst arrivals
- (C_{queue-decay}): missed passive windows and repricing/cancel tax
Operational metrics (new)
1) RABI — Receive Aggregation Burst Index
[ RABI = \frac{p95(\text{msgs per recv-batch})}{p50(\text{msgs per recv-batch})} ] High RABI indicates clumpy delivery dynamics.
2) GGI — Gap-Gini Index
Gini coefficient over inter-arrival gaps at strategy ingress. Higher GGI = more uneven timing.
3) QAS95 — Quote-Age Skew p95
p95 of feed age at decision time minus matched low-aggregation baseline.
4) BCR — Burst Coupling Ratio
Fraction of child orders emitted within top-decile feed-burst windows. Direct coupling between bursty intake and bursty execution.
5) BAT — Burst Aggregation Tax
Incremental IS in high-RABI windows vs matched low-RABI windows. This is the money metric.
Feature set to log in production
Kernel/NIC features
ethtool -k <dev>: GRO/LRO/adaptive-rx/coalescing statusethtool -c <dev>: rx-usecs/rx-frames and adaptive parametersethtool -S <dev>per-queue packet and drop counters- NET_RX softirq pressure (
/proc/softirqs,softnet_stat) - socket timestamp mode (
SO_TIMESTAMPING, HW/SW timestamp quality)
Feed-shape features
- messages per
recv()call (distribution, not just mean) - inter-arrival gap quantiles (p50/p95/p99)
- burst size and burst duration quantiles
- decision-time feature age (microprice/imbalance/refill)
Execution outcome features
- passive fill ratio in low vs high RABI regimes
- cancel/replace rate during burst episodes
- markout ladder (10ms/100ms/1s) conditioned on burst state
- implementation shortfall tail uplift by state
Identification strategy (causal)
Use matched-window attribution, not simple correlation:
- Match windows on spread, volatility, participation, and TOD bucket.
- Split by low/high RABI (or BCR).
- Estimate incremental tail IS with host and symbol fixed effects.
- Validate with controlled canary toggles (e.g., GRO off on one host pool).
If BAT drops materially after aggregation reduction while market covariates stay matched, the uplift is infra-causal.
Regime state machine
RX_CLEAN
- low RABI, low GGI, stable QAS95
- normal dispatch policy
RX_AGGREGATING
- moderate RABI rise, intermittent burst coupling
- apply mild anti-burst damping
RX_BURST_DISTORTED
- sustained high RABI/BCR with worsening QAS95
- stricter pacing guardrails and queue-risk controls
RX_SAFE_CONTAIN
- persistent distortion plus completion/SLA pressure
- route to cleaner hosts/path, favor certainty over queue-capture optimism
Use hysteresis + minimum dwell times to prevent state flapping.
Control ladder (ops + model)
- Tune receive coalescing first
- revisit
rx-usecs/rx-framesand adaptive-rx behavior under replay
- revisit
- Disable LRO for latency-critical feed paths
- LRO often harms timing fidelity for microstructure-sensitive workloads
- Evaluate GRO policy by host class
- some hosts can keep GRO off safely; others need calibrated compromise
- Decouple feed-burst and dispatch-burst logic
- enforce inter-child spacing floor and per-window burst caps
- Inject aggregation features into slippage model
- include RABI/GGI/QAS95/BCR in both mean and tail heads
- Route urgent flow to clean-ingress pool during
RX_BURST_DISTORTED- infra-aware routing can outperform aggressive repricing under distortion
Failure drills (must run)
- Coalescing sweep drill
- canary through rx-usecs/rx-frames settings; measure BAT response
- GRO/LRO toggle drill
- compare ingress burst stats + tail IS on matched symbols
- Burst-replay drill
- replay captured burst traces to verify state transitions and dampers
- Rollback drill
- prove deterministic rollback to known-good NIC/kernel profile
Anti-patterns
- Treating packet aggregation as a throughput-only concern
- Looking only at median feed delay while burst tails explode
- Using raw feed burst arrival as direct aggression trigger
- Blaming “market noise” before measuring ingress burst shape
Bottom line
GRO/LRO/coalescing can silently rewrite your execution clock.
If receive aggregation is not measured and controlled, your strategy trades on burst artifacts rather than live market cadence—and pays a persistent tail slippage tax.
References
- Linux kernel networking scaling (RSS/RPS/RFS/XPS, receive-path context): https://docs.kernel.org/networking/scaling.html
- Linux sysctl network docs (
net.core.netdev_budget*, receive processing knobs): https://docs.kernel.org/admin-guide/sysctl/net.html ethtoolman page (-k,-K,-c,-C, stats): https://man7.org/linux/man-pages/man8/ethtool.8.html- Red Hat network performance tuning guide (coalescing/IRQ practical guidance): https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/network_troubleshooting_and_performance_tuning/
- Kernel timestamping (
SO_TIMESTAMPING) documentation: https://docs.kernel.org/networking/timestamping.html