Surprising how time flies, its been 6months since the end of Round 1 with Round 2 closing now. Its been one hell of alot of fun, albeit soul crushingly painful at times. Yet on the whole 2012 has been a good year - not much pnl but gained a ton of experience.
Have been pretty quiet about what I`ve been up to, but unfortunately the current strategies do not have enough juice to make it worth continuing. It sucks ass but thats reality thus need to re-group yet again, pivot and soldier forward.
Here`s the gross PnL over the last 6months, real exchange, real trades, real money.
Have been pretty quiet about what I`ve been up to, but unfortunately the current strategies do not have enough juice to make it worth continuing. It sucks ass but thats reality thus need to re-group yet again, pivot and soldier forward.
Here`s the gross PnL over the last 6months, real exchange, real trades, real money.
Looks nice, grossed ~ $100+k in 6months, even impressive unless you trade HF yourself. In which case you notice the GROSS part and know how badly you get screwed by broker/exchange fees & tax, read the net pnl is only a fraction of this. The other realization is, for a HF strategy, for half a year this kind of gross pnl is quite frankly utterly shit.
But wait I hear, its a HF strategy, improve the latency! the latency man! the latency....... bake it into an fpga, build it for some network processor, hell go build that liquid nitrogen cooled 5Ghz overclocked monster machine and all your problems are solved... or maybe not.
Sadly better latency will not change anything.
So... show me the numbers! Lets measure the Tick2Trade register-to-register time, which means the nano(pico) second when the NIC`s register says there is a packet ready, to the nano(pico) second you bang the NIC`s register to say kick this packet. Visually it looks like.
Without further latency lol... here`s the register-to-register latency, real trades, real money, real exchange.
So... show me the numbers! Lets measure the Tick2Trade register-to-register time, which means the nano(pico) second when the NIC`s register says there is a packet ready, to the nano(pico) second you bang the NIC`s register to say kick this packet. Visually it looks like.
When you talk about latency, most people are using the socket-to-socket number. If you have lots of cash to burn, then you can purchase a Corvil and use the wire-to-wire number - the real absolute latency. We didnt have that choice so the register-to-register number gives a close approximation, as the latency jitter in the HW is fairly consistent (at the micro second level atleast)
Without further latency lol... here`s the register-to-register latency, real trades, real money, real exchange.
Above plot is the histogram of all trades over the last 6 months, with nanoseconds on the x-axis. As mentioned above, this is the register-to-register plot, so add 1usec (Rx) + 1usec (Tx) for PCIe transfer + NIC asic shenanegins + 10G SerDes/PHY to get the wire-to-wire latency. As you can see the median internal latency ~ 4.5usec putting it at under 10usec wire-to-wire, with a 95 percentile @ 8usec, 99 percentile @ 10.25usec But why is it multi-modal? The answer... the code evolved/improved over time so if we plot the above and compare with the last 10 trading days we get.
Which you can see the median for the last 10 sessions is around 3.7usec (~6usec wire-to-wire), 95 percentile @ 5usec, 99 percentile @ 6.75usec with the multi-mode clearly due to different versions of the code. First version took a bit over a month to code up (feed+book+gw+strat+other), 2nd version a week or two (optimization), all running on standard hardware nothing fancy.
I could reduce this to 1 or 2usec wire-to-wire with an FPGA but its completely pointless. Why? because at this level of latency, its irrelevant if your half the latency of your competitors. As the latency jitter inside the exchange is orders of magnitude more than the delta between you and your competitors - remember this!
Net result? technology and speed alone will not win you trades, this game is over / drawing to a close. I`ve seen this on multiple exchanges and usually boils down to the exchange not having any clue at this level.
.
.
.
Whats next? its clear to me higher strategy IQ is the way to go, thus my machine learning rant the other day. But I need to pay rent so available for tech contract work - see skillset
For contract work / interesting projects / collaborations / etc etc hit me up at hacking.nasdaq@gmail.com
Great blog!
ReplyDeleteOne question: how could I measure register-to-register latency?
Need to rewrite driver and tag every income message and send this tag back to nic in packet?
(In my case, I have some proprietary lib on both direction: rx & tx)
Thanks for reading.
ReplyDeleteyup register-2-register timing can only be done by hacking on the your NIC vendors code. Made a small patch to openonload to do this, onload`s tcpdump precision is shockingly bad.
mail me can send you a patch file.
Hi,
DeleteCan you share the patch you mentioned please? How to run tcpdump with onload?
Big tnx for answer!
ReplyDeleteAs I know openonload is only for solarfire, isn't it?
Right now I have only intel nic with intel closed drivers.
btw, I'm searching for sf-seller, but without result at this moment.