EMini Tickdata and the effect on orders

syswizard

syswizard

I witnessed this recently. A system built at the tick level of detail (yes, one tick at a time), produces one set of performance results for realtime and a DIFFERENT set of results with the same data feed for stored data or backtest results.
Can anyone explain this ? Is it due to delayed ticks....i.e. ticks that are streaming in not in perfect timestamp order ?
The other possibility is that the bandwidth and CPU of the workstation are not able to keep up in realtime with these fast data feeds.
I need an expert on datafeeds and specfically how the CME's data servers are sending out tick data. I have to say that in my measurements, I've seen tick rates as high as 2000 ticks per second for ES or NQ. Of course, I'm probably missing some, so the rate is likely higher.
 
Last edited:
First of all, 2000 ticks per second is not what we call high volume. Any computer and network bandwidth can handle that amount of data easily.

Finally, if your system has been optimized based on your backtest data, then it's normal that the results in real time are different. It's what we call curve fitting. This has nothing to do with the fact that you are using tick data.
 
You totally missed the point. The exact same code and parameters are being used for both backtest and realtime operations.
So we run realtime, get the results, then refresh from the cache....and get completely difference results. Same tick data provider, same tick data, same time frames. From all appearances, the data has changed because the code has not.

re: "2000 ticks per second is not what we call high volume."
Do you have evidence of that ?
BTW: This system successfully runs on a co-located server near the CME. So, based on that, it appears we are missing ticks with our local workstation....it's hard-wired 1 gig per second network with a 900 Mbps speed rating and 12 core processor....16 gigs ram.
 
When you say 'results', I'm guessing you are referring to trading results (P&L).
Because you cannot duplicate results in real time, otherwise it's not real time anymore.
And your code, I'm also guessing that it has been optimized to trigger signals using your backtest data.

2000 ticks per second is what, 200 kBytes, or 1.6 Mb/sec. I used to work at a place where we were processing tens of millions of tick per second, billions per day. I'm receiving and processing tick data for ES as well in real time. If your gear cannot handle that low volume, then Houston, we have a problem!!!
 
Aurora data feed run 10GB. And it’s extremely difficult to process direct feed at line rate and run any sort of calc on every tick.

I’d also question your historical data. Unless it’s pcaps you’ve collected yourself it’s probably also not every tick.

Unless you are 100% committed and actually colocated don’t try to look for alpha in tick data. Almost anything else you can possibly do will be an easier way to make more money.
 
it's the use of limit orders, in backtesting it will curve fit to give good results and in real time it fails.

you can not use limit orders in backtesting and expect the results to work in real time.
 
Thanks Garachen for that. I just got an education from the fine people at tickdata.
My goodness, I didn't realize how stupid I was regarding live market data. I learned about blocked trades, EFPs, out-of-sequence trades....and the CME's two options of trades protocol with consolidation and no consolidation.

And it’s extremely difficult to process direct feed at line rate and run any sort of calc on every tick.
More...
This is EXACTLY what we discovered.

Unless you are 100% committed and actually colocated don’t try to look for alpha in tick data.
More...
Good advice. Indeed: The system only works on a fast, co-located server.
Trying to run it locally ?.....hopeless.
 
MarkBrown said:
it's the use of limit orders, in backtesting it will curve fit to give good results and in real time it fails.
you can not use limit orders in backtesting and expect the results to work in real time.
More...
Mark - thanks for that, but the system is generating profits with limit orders.
But it only does it when the code and the server is co-located near the CME.
 
Are you using your own tick-data for the backtest? Or did you get it in a package from a vendor? ES has millions of data points (~10MM) every day, you can get thousands of updates in milliseconds. To know why your real-time vs tested is different you should spend more time studying data. I am surprised you claim to make money with limits even when co-located, if that will last you have done quite well given the apparent lack of knowledge.
 
  • Like
Reactions: rb7
syswizard said:
Mark - thanks for that, but the system is generating profits with limit orders.
But it only does it when the code and the server is co-located near the CME.
More...
lmao...colocation and limit orders make zero difference!! you can be in your parents bedroom in england and trade limit orders.

Funny they never mentioned to you anything about GTC orders or fill or kill orders.

The gtc orders get massive priority and can maintain their level in the book..ahem next day if you "take them down" at the cme and bring them back on the next day!
 
You must log in or register to reply here.
Back
Top