Technology stack for a high freq low lat trading system

[VectraMan]

Our Java code is Garbage Free, and very low latency.

Thinking about it some more... doesn't garbage collection still have to stop the world and trace all the references to all the objects to work out what's accessable? So it doesn't matter if you have no garbage, it's still doing the work as if there were. Or is there a way of turning it off completely.

[squarepeg]

Erlang?

Some shops use Erlang.

[eek]

This may be of interest to people

Mechanical Sympathy: Fun with my-Channels Nirvana and Azul Zing

[Contreras]

First problem was to choose between Windows and Linux. I decided to make it crossplatform but open to a single platform solution as well.
I checked QT for crossplatform GUI development but I think mixing it with boost would be problematic like using QT for UI and using boost threads. Also I have no experience with QT so I don't know whether it'll worth to dive in it.

Have you looked at wxWidgets (wiki / doc / forums ) ?

A "thin wrapper" with a common API onto the OS's native widgets, be that MS-Windows, GTK, etc.. Supports multi-threading as well. Doesn't carry the extra baggage of a widget library as QT does, so apps run faster and/or require less resources. Also less restrictive license than QT for commercial use (AFAIK). Disclaimer: I haven't used QT so my assessment is biased.

[SupremeSpod]

This may be of interest to people

Mechanical Sympathy: Fun with my-Channels Nirvana and Azul Zing

If you can afford his rate he does onsite training.

Well worth considering if you have specific issues.

[Bunk]

If you can afford his rate he does onsite training.

Well worth considering if you have specific issues.

Like double posts?

[SupremeSpod]

Like double posts?

It was an accident and if this wasn't the technical area I'd tell you to **** Off, seriously.

[pacontracting]

Low Latency Design

Typically - for low latency - you would want to minimise the time taken from the tick being generated from the exchange to the trade being accepted by the exchange.

For example - if your new system takes 10 microseconds to process a trade but seconds are wasted getting the tick to your server and then getting the intention to trade onto the exchange, you'll just end up with a large number of non-filled orders.

The tier-1 investment banks typically have this sewn up using water cooled servers, with custom FPGA network cards, 10GB low latency networks, running custom built software (always Linux and C++) and the best mathematical minds continually refining their automatic trading algorithms. Physical latency is further reduced by hosting these servers in the same building as the exchange matching engines. In other words - for pure low latency - forget it.

There is obviously a market if you don't want to compete with the 'big boys' and want to look into offering a simple to use product that balances ease of use and perhaps offers something new and you just want to get the trades in as fast as possible within the limitations of your infrastructure.

In this case, a lot of the tier-1 banks also want to trade on esoteric exchanges or with certain products, but latency isn't the most important issue (low latency rather than ultra low latency). This is where Java wins as it is easy to develop for and absolute speed is not required (perhaps because someone is pushing a button to decide a trade rather than the machine making the decision as in Ultra-Low Latency environments).

So - a typical stack in this case may be Java, layered on Linux. The GUI may be an apache hosted website on the same box). Get some decent hardware like HP Proliant or similar. The expense of low latency network cards and switches may not be required and look what's upstream and downstream from your proposed environment e.g. do you have internal risk system that need to be consulted before you can make a trade.

So to summarise - it's not the speed of your part of the whole trade lifecycle that's important; it's the latency on the whole tick to trade journey.

[bilgehan]

So - a typical stack in this case may be Java, layered on Linux. The GUI may be an apache hosted website on the same box). Get some decent hardware like HP Proliant or similar. The expense of low latency network cards and switches may not be required and look what's upstream and downstream from your proposed environment e.g. do you have internal risk system that need to be consulted before you can make a trade.

So to summarise - it's not the speed of your part of the whole trade lifecycle that's important; it's the latency on the whole tick to trade journey.

This is good insight thanks and backs my latest decision.

BTW sorry for late reply, I just signed a new 1 year contract outside UK (will use C on RTOS and C#), then will come back to UK. As this trading system is a side project I decided to use technologies I use at work. In this case it'll be C#, I decided not to use QT/C++ , don't want to endevour a QT learning process.