> I think the author would have been better suited without mentioning HFT, maybe algo trading model?, as its a lighting rod for controversy.
Don't be so quick... in a world where keeping score is simple and the odds are tilted for many, any publicity is good publicity.
> 4) Back testing, no HFT trade idea's go into production without backtesting, Every HFT firm is different but I think they'd all adhere to this rule.
I'm sure the majority do. But I really didn't. The problem with backtesting low latency (by which I mean switch-to-switch roundtrips of < ~ 50us) is there are so many sources of jitter the data is basically "mean of x, st dev of 6x^3". Too much noise to signal to make it worth it.
So I would run something "in sim" for a while on live market data but simulated execution. I never looked for profitability--I looked for predictability. If you know the knobs on your system, you can make it work in any market. If you don't know the knobs, you have no business trading it. After a run of a week or so with no major problems I'd go into production. BUT:
> before you write anything else, you write hte risk system.
Oh Dear Lord yes. Not counting life-supporting, military, etc. tech, these are some of the sharpest tools you can imagine. Knight lost $440mm in less than an hour. And they were decidedly not of average expertise. That failure was a much bigger deal than most realize. Luckily smart people noticed and a lot of risk stuff changed after that (imo that was when people finally started to say "fast enough, I need to generate smarter orders").
> 2) The system has no rate limiter, what do you do when the quotes come in too fast for you to deal with?
I've been out of the guts for ~2 years, but by universal unforgiving law, the volume of quotes has got to be ridiculous now. People talk about "low latency" when they're talking about serving static HTML at 1000/s. So few people have actually seen the nuts and bolts of feed handlers--it's not their fault, this isn't widely available stuff--but the traffic spikes are mind-boggling. Good adapters combined with a tuned network stack will translate signal into "book" data, meaning usable basically, in ~ 5us. Meaning they do that 200 times per MILLIsecond. And it's not enough sometimes. And you and your rival firms are spending a lot trying to make that number 4us. Blah blah blah, I kinda miss it.
I agree with you on back-testing. Trying to model order book dynamics across multiple exchanges accurately is something of a fool's errand (especially in pro-rata markets). Running stuff in sim generally lets you iron out flaws and then you can just plug and play to see if it pays. Heh, I used to just plug and play directly with small size as a test rather than using sim since my firm didn't have a usable sim set-up at the time. Just put extremely limiting risk limits in terms of order sending rates on and then cut it off it loses too much in the experiment and move to the next one (yes, this did make strategy choice pretty path-dependent...).
RE rate limiter: For this dude's implementation I don't think it matters. He's using IB (a retail broker) for his data rather than the direct market feed. IB sends a sample of market data rather than every single book update and I think they do it at a rate slower than ~10ms so he probably won't run into problems. Heh, I remember some fun times figuring out the optimal way to handle getting spammed by the exchange. It is a neat industry, but kind of makes you feel a bit like a societal leech some times (I know, we're risk salesmen making markets more efficient and all...).
> I think the author would have been better suited without mentioning HFT, maybe algo trading model?, as its a lighting rod for controversy.
Don't be so quick... in a world where keeping score is simple and the odds are tilted for many, any publicity is good publicity.
> 4) Back testing, no HFT trade idea's go into production without backtesting, Every HFT firm is different but I think they'd all adhere to this rule.
I'm sure the majority do. But I really didn't. The problem with backtesting low latency (by which I mean switch-to-switch roundtrips of < ~ 50us) is there are so many sources of jitter the data is basically "mean of x, st dev of 6x^3". Too much noise to signal to make it worth it.
So I would run something "in sim" for a while on live market data but simulated execution. I never looked for profitability--I looked for predictability. If you know the knobs on your system, you can make it work in any market. If you don't know the knobs, you have no business trading it. After a run of a week or so with no major problems I'd go into production. BUT:
> before you write anything else, you write hte risk system.
Oh Dear Lord yes. Not counting life-supporting, military, etc. tech, these are some of the sharpest tools you can imagine. Knight lost $440mm in less than an hour. And they were decidedly not of average expertise. That failure was a much bigger deal than most realize. Luckily smart people noticed and a lot of risk stuff changed after that (imo that was when people finally started to say "fast enough, I need to generate smarter orders").
> 2) The system has no rate limiter, what do you do when the quotes come in too fast for you to deal with?
I've been out of the guts for ~2 years, but by universal unforgiving law, the volume of quotes has got to be ridiculous now. People talk about "low latency" when they're talking about serving static HTML at 1000/s. So few people have actually seen the nuts and bolts of feed handlers--it's not their fault, this isn't widely available stuff--but the traffic spikes are mind-boggling. Good adapters combined with a tuned network stack will translate signal into "book" data, meaning usable basically, in ~ 5us. Meaning they do that 200 times per MILLIsecond. And it's not enough sometimes. And you and your rival firms are spending a lot trying to make that number 4us. Blah blah blah, I kinda miss it.