If enough people start following this blog I will share the "secrets" to building ultra low latency systems and start open sourcing code including the SubMicroFix engine ... possibly the fastest fix engine on the planet !
SubMicroTrading has
been in development for over 4 years but is now on hold. It has been connected
for testing to Eurex and CME and BSE but its not in production anywhere. Put
that down to me being a technologist and a lousy marketer in what is after all
a fairly small and difficult to approach market.
WebSite : www.SubMicroTrading.com
To summarise it’s a
scalable, component based ultra low latency trading framework. It has Order
Management, Market Data Sessions, Trading Sessions and all you need to build
ultra low latency trading systems.
- AntiSpring . . . application bootstrapper, property file based, GC free, interceptor/proxy free, simple zero runtime overhead, component loader supporting dependency injection.
- Async Flexible Logger (copes with massive activity bursts 100,000+ log events per second mitigating GC).
- MemoryMapped Persistence with ISAM, with jitter avoidance when switching pages (can also free pages without GC finalisation) ... used for recoverable indexed session persistence.
- Low level utilities and GC free collections e.g. Int2IntMap, pooling pattern, java thread affinity, spinning thread multiplexors.
- SubMicroFix (sub microsecond fix engine, includes session state management, JMX admin, generated encoders/decoders). Tested against CME.
- Native binary trading session support (sub microsecond) for ETI (Eurex/BSE), FIX, Millennium, UTP.
- Native Market Data session support for FastFix tested with CME and BSE pcaps, SBE, ITCH.
- Session Drop copy support.
- Order Management System (sub-microsecond, support for in-line client limits, trade cancel/corrections and exchange normalisation .. excludes non latency sensitive trading functionality such as GTD orders).
- Basic Exchange simulator (can simulate any exchange in the model).
- Scalable Market Data Controller and Book conflation .. strategy snaps book to avoid mistrading due to concurrent book update during strategy cycle.
- Trading GUI shows price blotter, market orders, executions and supports multiple on-screen full depth books.
- Core strategy framework, include CME session loader to generate CME sessions on the fly as required by strats.
- Core strategy extensions with Spread Arbitrage Example and useful pipeline scalability example.
- Code Generator
Book Management -
for an algo trading system this is the most critical component. The Book needs
to asynchronously allow updates while minimising potential for blockage by
strats using the book.
SMT uses conflation
to prevent strategies having to process old ticks. When a strategy is
processing a tick update it snaps the book taking a local copy (SMT optimizes
this so a snap is shareable with no contention) to allow strategy to process
the book atomically. After all if a strategy is acting on a BBO where the ask
changes after it has just read the bid is a high level risk.
SubMicroTrading can
process over 800,000 market data tick updates per core per second. Can decode a
fast fix message in nanoseconds. Update a book in nanoseconds and encode an
order to market in nanoseconds.
The SubMicroTrading system
(with Intel servers from 2013) has been measured in a controlled lab with
TipOff, wire to wire for "tick to trade" with average of 4
microseconds at a rate of 800,000 ticks per second (that includes UDP tick hop thru Solarflare on OpenOnload and TCP
order hop total overhead of over 2+ micros).
Redline, Chronicle, Onyx, FixNetix all have part of the above functionality. They are all used currently in production systems and have full time support. SubMicroTrading has not been proven in production, but it is provided with exchange simulator and its performance can easily be proven. Dont forget also that the SOURCE CODE is available. Many of the techniques I used have been proven in production eg object pooling, CPU spinning etc. As for which is quickest ... that I would expect to depend on the trading scenario ... peak tick rates, number of market data sessions, number of actively ticking books, number of orders generated per second, number of concurrent strategies triggered per tick.
No comments:
Post a Comment