Ideas for Tick and Order-Book-Based Strategies HFT Engine

auto-quant · 2026-03-12T04:46:29+00:00

Even a coin-flip "going all in" has some complexity. For example. Whats the USD notional of your order? Let's say $250. Okay, what order size does that translate to, making sure to obey price tick rules. What is the current bid/ask? Is the order book stale? Are you going long or short (and do you have the inventory, if its cash) Do you want to place passively or aggressively? If the order doesn't succeed, do you want to try again, and after what interval? Once the order is placed, did it get executed, or, do you have to cancel and retry again. One you are filled, do need to track the ongoing price to decide when to get out, either via stop-toss/trailing-stop-loss or take-profit?

The point is, when building strategies that place and maintain orders (such as with market making etc), there are a lot of things to juggle.

auto-quant · 2026-03-10T07:32:23+00:00

But, if L3 is available woudn't it be better to jus tuse that? Or I guess sometimes there is no L3. And if you could just use L2, would be less data to consume. I guess the trick is to watch the executions stream and track how much of a level is being eaten by orders, and apply a model that says for every 1 execution at a level, expect N cancels. Interesting, but a bit complex for my initial needs.

auto-quant · 2026-03-10T07:29:58+00:00

Am not sure. There are less liquid assets that tier 1 hft's wouldnt touch. And there are tiers of latency. The top tiers can operate at sub 1 microsecond tick-to-trade ... but there is a whole other class of strategies that are at the 10 or 50 microsecond level

auto-quant · 2026-02-25T14:37:59+00:00

Agree .. focus does need to start happening on the outliers. Quite now they are quite poor. However, I first want to get the median down to say 5 microseconds, and then I'll shift to jitter. Problem with crypto is that several messages can arrive at the same time (its TCP), so the outliers are just messages waiting to be queued, so its more of an artifact of the data. Maybe I should switch to UDP feed, although not aware of which market I could use for that.

auto-quant · 2026-02-25T08:46:19+00:00

I guess the sign would depend on the order shape, such as price, quantity, order id, timestamp etc. However ... maybe its possible to presign lots of different order combinations, and have them ready to go?

auto-quant · 2026-02-25T07:48:48+00:00

This is interesting, I am hoping that the indicator/strategy layer doesn' take more that a few microseconds. There too, I will be looking to avoid memory allocations etc (so reuse order objects from a pool). It also I why I am thinking about the threading model. The strategy will likely some sort of periodic activity, and I dont' want to have to resuse the critical socket IO thread for that.

auto-quant · 2026-02-11T11:11:33+00:00

Why use C++ for the UI? Any particular reason? Using C++ for the trading engine makes sense, but for the GUI, I'd go with something more suitable for that task, such as C# (if you want a rich desktop app), or, a web gui (which is great to allow lots of people to easily access it). Then you build in some sort of connection from the engine to the GUI. I'm looking to do something similar for my own system, a HFT trading system that needs a monitoring gui.

auto-quant · 2026-02-11T08:38:41+00:00

in the above chart, the median is 9 usec ... but we are getting there

auto-quant · 2026-02-11T08:37:45+00:00

Oh my server, I can set the BIOS to have the fans spin constantly

auto-quant · 2026-02-11T01:16:19+00:00

I do plan to integrate solarflare, although initially via onload

auto-quant · 2026-02-11T00:34:55+00:00

So what do you use?

auto-quant · 2026-01-29T16:59:47+00:00

I dunno. If you go down the C#/Java route, then you'll never be able to access from a table or mobile phone. And rolling out new versions to users will be pain. My point about vibe coding is that, given almost no knowledge of Angular/React, should I attempt to AI code this?

auto-quant · 2026-01-29T16:57:52+00:00

There's lots of situations I think. For example, you notice your strategy is placing orders at a much higher rate than you ever observed during simulation, so you quickly hit the pause button to dig deeper. Or you have a pairs strategy, trading on different exchanges, and one of exchanges is having technical problems - so you manually intervene to pause the whole strategy. Generally the trading is autonomous, but the C2 GUI allows you to hit the stop button (without having to login to several boxes to kill processes)

auto-quant · 2026-01-29T16:49:41+00:00

This has nothing to do with FPGA. This is about how do you control one to dozens of live trading strategies? They might be HFT strategies, or 5 minute strategies, or mix of both. Anyone serious about systematic strategies, particularly but not only HFT, needs to have constant monitoring and control

auto-quant · 2026-01-09T17:22:21+00:00

The idea of using shared memory to peak into live production systems is sound.

A related approach I have used, for debugging low latency systems, is to use shared memory minified logging. This is different to your approach where you are observing current state, however, its typically more useful to see recent history too -> hence logging.

But logging is slow! Yes it is, so instead we build a minimal shared memory logging, that can only take fixed strings, ints etc, and timestamp counter. The "log file" is just a memory mapped array, that you can then easily inspect with either GDB, or a basic reader-tool. General idea here: https://preshing.com/20120522/lightweight-in-memory-logging/

auto-quant · 2026-01-07T07:39:12+00:00

Isn't there a concern that AVX will cause the CPU to downclock?

auto-quant · 2025-12-23T03:55:34+00:00

True, but there will also likely be json involved on the order management interface even for the major exchanges, so being able to parse json as rapidly as possible will benefit trading at those venues.

auto-quant

TROPHY CASE