What is Chronicle Fix

Chronicle Fix is a fully featured Fix Engine which can handle all flavours of fix.

What distinguishes it from the competition is pure speed!

Built on our Chronicle libraries and with the Chronicle philosophy it employs amongst others, the principles of:

  • Zero copy – to eliminate GCs
  • Runtime code generation – to reduce code size for efficient CPU cache usage
  • Smart ordering – to optimise parsing

All these combine to allow Chronicle-Fix to achieve these results parsing and logging a NewOrderSingle:

Screen Shot 2016-04-26 at 16.37.38

Note : when evaluating FIX publishers, we recommend measuring them in a real running system rather, than going by an idealised view of software from a micro-benchmark.

Is it all about Speed ?

  • We believe that Chronicle-FIX is just about as fast as you can get in Java.

  • But we designed the software from the ground up to be the easiest Fix Engine to implement as well.
  • Even if you don’t need the raw speed of Chronicle-FIX we think that you will really see the benefits of our unified FIX model especially if you have to talk a number of dialects of FIX.

  • We only give you the code you need. We’re pretty sure you don’t use more than 5% of the FIX specification. Why do you need to clutter your code with more FIX than you actually use? Well you don’t – and you’re code will become so much cleaner, simpler and faster.
  • But is it a pain to have to generate a model to generate your runtime? Not at all – it’s actually a really easy process to define a model file and we can even automate this with our model generator which will create an optimised model from your fix messages. After that it’s one click to have your clean, uncluttered runtime generated for you!

And there’s more…

  • We use Chronicle-Queue (a super optimised low latency version from the Chronicle Enterprise suite) to log every fix message.

  • You can easily replay all your historic fix messages from a chronicle-queue into Chronicle-FIX, to give the deterministic replay. Or in other words, you can feed your test systems with the actual real historic data. So, no more made up or generated data that can’t reproduce production issues.

  • You can also use this technique to test experimental strategies.
  • Chronicle Fix can be used stand alone. But it really makes sense to use it as your entry point to the rest of the Chronicle products and benefit from the ultra low latency we can provide if you use Chronicle as the backbone throughout your systems.

Why Chronicle Fix

  • You need a really low latency Fix Engine

  • You want a really easy to use Fix Engine

  • You want a Fix Engine that features deterministic replay – live or batch

What will you get from us

  • You will of course get Chronicle FIX.

  • Access to our enterprise GitHub repo where you can read, fork and create pull requests on our code – It works exactly like the open source. You can be as involved as you like.

  • As much support as you need to help with any issues that might arise either with Chronicle FIX itself or with your project as a whole. The understand that the FIX engine is usually only a small part of a system and we can use our experience to help with latency issues with other parts of your project should you need it.
  • A fair price. Although this is highly specialised software we don’t charge a fortune for it and we believe you will find us very competitive when compared to similar solutions.

How it Workscog

  • The parser has been optimised to accept fields in an expected order. Our default implementation has the order the fields appear in the fixprotocol.org documentation. However, the fields can be in any order allowed by fix but this will be a little slower.

  • For generating you do the reverse. You call an interface which writes the fix message as you add the fields. Ideally you call the fields in the expected order, this speeds up parsing.

  • By recycling the buffer and using object pools and mutable StringBuilders we can send/receive messages end to end without significant garbage. Our aim is less than one byte per message on average.

  • We design our systems to produce less than 1 GB/hour of garbage. At this point a 24 GB Eden space takes 24 hours to fill up. Ie no collections all day.

  • You can save around 0.2 micro-seconds if you drop computing or checking the byte sum.


Chronicle Fix Offers:

  • A low latency, recyclable, configurable FIX 4.2, 4.4, 5.0 implementation for inbound FIX message parsing and outbound FIX message transmission.
  • Pre-allocates the memory for FixMessage objects. This is intended to reuse objects thus avoiding dynamic memory allocation.
  • Fix parser, around 1 us 99.9% of the time for medium sized messages.
  • Fix message generator, around 1 us 99.9% of the time for medium sized messages.
  • Optional persistence of messages and latency checkpoints in and out.
  • Optimise latency for FIX in-order messages with fallback for out-of-order messages.
  • Scalable to 10s of connections per server with minimal latency impact.
  • Session handling – login/out and heartbeat.
  • Integration with existing data structures in a zero copy manner.
  • High performance test client to drive the system to its limits.
  • Tools for minimising garbage and enabling zero copy.
  • Optimise networking to work efficiently with Solarflare network cards.



Evaluation Copysales@chronicle.software
Enterprise Customers GitHubSource Code