[erlang-questions] trading systems
Thu Oct 1 20:56:44 CEST 2009
On Oct 1, 2009, at 7:43 PM, Kenneth Lundin wrote:
> Please explain more.
Feel free to ask pointed questions.
> I got the impression that latency is a big selling point for
> trading systems
Correct. If you can react to the market faster than the next guy
then you win. There's even a new kind of high-frequency trading now
called latency arbitrage .
> but in reality there might be
> other factors that are more limiting and makes the hunting for latency
> under a certain level unnecessary.
There may be other factors but people pull tricks like disabling RTTI
in their C++ code, not using exceptions and moving as much as they can
to the compilation stage with C++ templates. This is in addition to
cache-friendly and lock-free data structures.
No need to put myself at a disadvantage from the start by picking an
inefficient approach to price data management and processing.
> A backtest system is not run in real time and there should be no
> absolute requirements on latency?
It's pointless to build one system for backtesting and another one
for execution. I'd rather have a single system handle everything.
> You have a server supporting some protocol (probably FIX) , the price
> quote arrives this way?
In my case it's gonna be via a C++ API, over the network.
> The decision is taken at the server?
> The trade order is handled in the server or sent to another system?
The order is sent to the broker via a C++ API, over the network.
> From where , to where is the latency measured?
The latency I'm talking about is measured from the moment the price
quote is received by Erlang to the moment Erlang tells the C++ API
to send the trade to the broker.
There's also the network latency but it should be minimal for a
server co-located at the exchange data center or close to it.
> From your reasoning it seems that the encoding/decoding +
> communication latency is not part of
> the important latency? In that case why not?
Encoding and decoding is part of the latency but network latency is not.
> Anyway there must be som latency value that is just good enough and
> going below that is just unnecessary?
No such thing :D . It's a war out there over who can go down faster.
People are embedding FIX adapters and trading strategies into FPGAs
for microsecond latency . Incidentally, the HPC Platform software
is written in Lisp. It's mostly compilation and VHDL generation, though.
fastest mac firefox!
More information about the erlang-questions