I am writing a blackbox model that will react to each market data update (tick) by placing a new order in the market. Without using FPGA, what is the fastest tick-to-trade time that I can expect to achieve with the most modern CPUs?
$\begingroup$
$\endgroup$
1
-
1$\begingroup$ Are you asking what you in particular can expect, or are you asking what is possible? It takes a lot of very difficult software engineering to get to the limits of possibility, so you might not find that you are willing to do what it takes to get there. $\endgroup$– deftfyodorCommented Nov 10, 2018 at 18:10
Add a comment
|
4 Answers
$\begingroup$
$\endgroup$
1
That will depend on the protocol you are using for market data (UDP, FAST, MDP, ITCH, etc.) and order routing (FIX, OUCH, etc.). For example, the latency to parse a UDP tick and to place a FIX order was around 8 micros as measured by tcpdump, using CoralFIX and CoralReactor.
Disclaimer: I'm one of the developers of CoralFIX
-
$\begingroup$ Are you bypassing the kernel in this case? If yes, can you still measure the latency this way using tcpdump and wireshark? $\endgroup$ Commented Sep 25, 2016 at 11:33
$\begingroup$
$\endgroup$
It is pretty easy to get down to 50us tick-to-trade measured from start of MD packet on wire at switch to start of trade order at the switch, at the 99th percentile. 10us takes user-space networking, lock-free coding, isolated and pinned cores, profiling and kernel tweaking. (So, still not terribly hard). 5us (99th percentile) takes cache optimization and allocation, branch reduction, and TLB/memory optimization. This is decent, and where many people should stop. 2us (99th) is very hard to do with software, and probably not worth the marginal effort over FPGA (where 2us is, in turn, relatively easy). State of the art FPGA is below 200ns now, probably lower.
EDIT: when evaluating vendors, always be sure to ask for 99th percentile numbers. 2us median is pretty easy, but 2us in tails is hard.
$\begingroup$
$\endgroup$
I do not understant your question. In terms of latency, you have
- your distance to the exchange
- the network latency
- the tcp/ip layer
- your operation system
- the speed of your code
If you just talk about the last step (do not forget you have to count the other steps twice) and you want to go as fast as possible, just write in assembly. In most assembly manuals you will find the execution time for each instruction (for generic considerations about how to count speed, you can have a look at this link). If you write in C, you can have a rough idea of the exec speed if you keep in mind how the compiler translate your code in assembly.
But frankly, this last step is from far the fastest of the five steps... Using fpga is about to go fast at tcp/ip and os steps mainly.
$\begingroup$
$\endgroup$
I would say something around 1/5 milliseconds. Are you connecting through fix? Any specific engine?
