Ali H. Askar

Part 3: Measure once, cut twice: telemetry and Amdahl's law Most people optimise their bot without ever measuring it. It's like trying to lose weight without a scale. The bot from part 2 runs from my laptop in Singapore. It felt slow, and my first instinct was to dive into the Rust decision code and optimise the shit out of it. I was very wrong. It was nowhere near the bottleneck. Then I remembered Kevin Bowers' @jump_firedancer talks at Breakpoint, and measured first. One trip, step by step The bot now timestamps every step from a Binance price update to our new order resting on Bullet, and exports it all to Grafana. Averaged over 5 minutes: 1. Inside Binance: 0.4ms 2. Binance to us: 41.6ms 3. Waiting in our queue: 0.010ms 4. Our code deciding (tick-to-trade): 0.0057ms 5. Order to live on Bullet: 190ms End-to-end: 232ms Amdahl's law Speeding up one part only helps as much as that part's share of the total. Our trading logic is 0.002% of the trip. Make it 99% faster and the whole trip gets about 0.002% faster. Days of work, basically nothing to show for it. That's the whole point of measuring: know where to look before you spend your time, or Amdahl's Street Justice (as Kevin Bowers likes to call it) gets you. And the numbers already tell us what to fix: • Binance to us (41.6ms) is distance. Part 4 moves the bot next to the exchange. Hint hint, colocation. • Order to live (190ms) is our naive executor. It cancels the old order, waits for Bullet to confirm, then places the new one, and waits on every request. Part 6 fixes that. Two traps when measuring • Use Rust --release builds. Debug builds skip the compiler's optimisations, and made our code look 3-5x slower than it really is. More on squeezing Rust in part 9. • Sync your clocks. Binance to us compares Binance's clock with your laptop's, so if yours is off, the number is off. Mine drifted 433ms behind, so messages arrived before they were sent. That's why end-to-end only uses the exchanges' clocks. Details in the github Now everything is timed and we have a target. Measure first, then fix the biggest number. Tomorrow we move the bot to Tokyo, next to the exchange.

How I made $6K PnL in 30 days on $10K principal market making perps ($158m+ volume). The strat was entirely built by me and my quant, Claude (he won a national math competition in China). Last night I asked if you'd want a guide. Hundreds of you said yes, so here it is: HFT for Dummies. The honest timeline when I did it: - Days for basic harness and venue integrations. - Weeks to get it semi-competitive. - Months to really tune and get it properly profitable. This series can hopefully shortcut the learning curve for you. I've been writing trading bots since 2017. It's how I got into crypto (free market data!), and how I met my co-founder. Back then the barrier was high. You had to know how to code, to study data to find alpha, and to grind devops to have systems not blow up in production. Thankfully I taught myself Python and later Rust, but not everyone has a CS degree. Nowadays with LLMs, anyone can have a skilled quant in their pocket. I use it for data analysis, strategy tuning, research and alpha generation and infra optimisation. It's a ridiculous time saver. I'm extremely bullish on one-person quant shops. I think this will be a huge trend this next decade as finance comes on chain and market data and connectivity are accessible to anyone. I've already met many hobbyists who've made a living trading on e.g. Hyperliquid, enough so to quit their day jobs. What we'll be building A delta-neutral, reference-price market maker. Binance is where most price discovery happens. We stream its market data, use it as a reference price, and quote a bid and an ask around it on another venue. I'm using @Bulletxyz because it's the one I know best. Market making is the business of picking up pennies. Mine are under half a basis point per dollar. Enough pennies add up at the scale of millions of volume. The catch is speed. If the market moves and you're slow to update, someone lifts your stale quote and you're the exit liquidity. It's a fun game of algorithmic cat and mouse. On Bullet, takers get a 100ms speed bump. Why? It gives soon-to-be market makers like you a safety buffer so you don't get steamrolled by billion dollar firms with microwave towers. The goal The goal: tick to order sent in under 10ms. Stretch goal: under 1ms, which is very achievable if you're determined. We'll also focus on minimising jitter (randomness) because your slowest orders are the ones that will lose you the most pnl. Agenda: I'll aim to post one topic a day, going from easy wins, and getting progressively more deep in the weeds. If you work at any HFT firm this will all be elementary stuff, but hopefully it's helpful for newcomers. Saving seconds 1. Basic intro to algo-trading (this post) 2. Running a simple market maker from your laptop 3. Measure once, cut twice: telemetry and Amdahl's law 4. AWS: Infra and colocation Saving millis 5. Stop polling: websockets are your friend 6. Optimising order execution 7. How to not get rekt by API rate limits 8. Linux tuning: CPU pinning, IRQs and other nerd stuff Saving micros (diminishing returns, but fun) 9. Optimising the hot path with CPU profiling in Rust 10. AWS: the last mile 11. Bonus: nonces (and other DeFi quirks) I'll try share some open source code along with it. Don't expect to be beating Jump in the orderbooks just yet. It should be a good baseline that you can extend and take it as far as you want (you can take it pretty far!). Tomorrow: setting up a basic MM in Rust, the architecture of which will roughly follow the diagram attached below.