We've worked through all sorts of issues with OEC. Good news is their support team has been responsive. Bad news is having to work around issues in the first place. Charting issues, Level II Data out of sync, receiving different time stamps from API versus their platform, orphaned orders. To be fair these issues have been relatively minor and resolved quickly. Overall their Onelink API is decent and worth a look. Same with TT over the years... Singapore support here we go again...
Ninja Zen no more unfiltered data?
- Thread starter RandomX
- Start date
dcraig, I agree with you 100%. My reasoning is that the abstraction layer would involve copying all data an extra time. My system is not monitoring as many instruments as yours so I was not sure how it would handle monitoring hundreds of instruments at the same time. Also, my ticks arrive out of order so I need to sort them. Currently, I just ignore this issue and sort everything at the end of day. I am not doing anything realtime yet so this works. But eventually, I will need to implement something to handle the sorting in realtime. How are you storing your data? Right now I am storing everything in text files. I was using binary, but I found that after compression, there was not much difference in file size.
Last year, I did a speed comparison of Java vs. C++ on an E6700 running most of the TA-LIB indicators. I found C++ to be about 1.4x faster, but in the end, I opted for productivity. I am just much more productive with Java and most importantly, the Eclipse IDE. Also, threading is a lot easier to implement in Java than C++ which is where I think I will get most of my performance gains.
"Equity futures now send milliseconds in iLink timestamps, as options and FX futures do today. FIX/FAST timestamps will always default to â000â milliseconds and should not be relied upon by customers"
Basically CME says they are able to process order messages in 1/100 of a second. But they purposely omit milliseconds from their time stamps...
Message Response time from 2008 to 2009
ES From 16.95ms to 9.45ms
6E From 11.73 to 3.90 ms
Page 49: http://www.cmegroup.com/globex/file...4_ChicagoNY.PDF
Basically CME says they are able to process order messages in 1/100 of a second. But they purposely omit milliseconds from their time stamps...
Message Response time from 2008 to 2009
ES From 16.95ms to 9.45ms
6E From 11.73 to 3.90 ms
Page 49: http://www.cmegroup.com/globex/file...4_ChicagoNY.PDF
Just the CME/Broker side... you still have your side including data transport to measure in order to determine your round trip execution time.
Remember these are averages... you'll see response slip to 20+ ms during high volume fast moving runs.
If you stage your orders on your PC and trigger release to your broker you'll have network latency and processing lag which can easily exceed 100ms. You can always have resting orders placed in the exchange limit order queue.
This is where your broker's platform can make a difference.
If you can stage your orders on your broker's servers and released to the exchange on a trigger your response times are optimized.
One example is CME globex does not support trailing stops. These orders are simulated and managed on your broker's servers.
Remember these are averages... you'll see response slip to 20+ ms during high volume fast moving runs.
If you stage your orders on your PC and trigger release to your broker you'll have network latency and processing lag which can easily exceed 100ms. You can always have resting orders placed in the exchange limit order queue.
This is where your broker's platform can make a difference.
If you can stage your orders on your broker's servers and released to the exchange on a trigger your response times are optimized.
One example is CME globex does not support trailing stops. These orders are simulated and managed on your broker's servers.
Quote from maxima120:
Thank you
so the order entry response time is difference between posting an order and getting ACK back ?
Is that right?
Look at those soybeans!Is it culture of vegetarins drives it up ?