[erlang-questions] trading systems

[Michael Truog]

One thing you might want to consider before building the system is the
cost of the data to actually do the type of trading you want to do.  If
you are trying to do low latency arbitrage type trading you might want
to relocate to New York for obvious reasons.  The data costs of a
real-time feed with reliable data might be a bit bothersome and would
dig into any profit.  I think that after you figured out the constraints
on the system due to network and data the design would take shape.  The
design could be as simple as using Tradestation libraries, but any
slippage on order fills would be something you would discover after you
finished creating the system (and that sort of discovery is negative).

- Michael


Joel Reymont wrote:
> 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
>
>
>
>
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>