[erlang-questions] trading systems

[Joel Reymont]

Kenneth,

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 [1].

> 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  
using
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?

Right.

> 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 [1]. 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 [2]. Incidentally, the HPC Platform software
is written in Lisp. It's mostly compilation and VHDL generation, though.

	Thanks, Joel

[1] http://www.google.com/search?client=safari&rls=en&q=latency+arbitrage&ie=UTF-8&oe=UTF-8
[2] http://www.hpcplatform.com/

---
fastest mac firefox!
http://wagerlabs.com