Quote from maxpi:
I just ran an identical test on daily and 390 minute data in TS8 and got 76 trades out of the daily and 84 trades out of the 390. This system is worst case in that it depends on data highs and lows wherein lie much of the troubles.
I'm thinking you test a system and then you roll it out with small capital allocated to it to "really" test it. Not much point in going with the "in sample-out of sample" routine if you are not too sure of the data anyhow.
Quote from EricP:
To do this, you simply need a way to timestamp events to the nearest millisecond. I'm not sure if the off-the-shelf automation tools allow this, but this should not be difficult in custom built automation systems. For me, I record the timestamp of ever order BEFORE it is sent out. Then, I also timestamp the moment the order was confirmed by the brokerage order server, confirmed by the market, as well as when it was executed or cancelled. By knowing your system lag times, you can help troubleshoot additional slippage that may have been caused by additional delays in your order speed, allowing you to troubleshoot the cause of the delay.
For example, the following are some of the results I have gotten from speed tests with various brokers:
*************************
<b>Broker A:</b>
.... <u>INET:</u>
........ OS Confirm: ............... 0.305 seconds
........ Market Confirm: ......... 0.305 seconds
........ OS Cancel Confirm: .... 0.253 seconds
........ Market Cancel Confirm: 0.253 seconds
.... <u>BRUT:</u>
........ OS Confirm: ............... 0.273 seconds
........ Market Confirm: ......... 0.298 seconds
........ OS Cancel Confirm: .... 0.250 seconds
........ Market Cancel Confirm: 0.250 seconds
.... <u>ARCA:</u>
........ OS Confirm: ............... 0.294 seconds
........ Market Confirm: ......... 0.494 seconds
........ OS Cancel Confirm: .... 0.258 seconds
........ Market Cancel Confirm: 1.258 seconds
*************************
<b>Broker B:</b>
.... <u>INET:</u>
........ OS Confirm: ............... 0.047 seconds
........ Market Confirm: ......... 0.236 seconds
........ OS Cancel Confirm: .... 0.016 seconds
........ Market Cancel Confirm: 0.188 seconds
.... <u>BRUT:</u>
........ OS Confirm: ............... 0.047 seconds
........ Market Confirm: ......... 0.214 seconds
........ OS Cancel Confirm: .... 0.016 seconds
........ Market Cancel Confirm: 0.186 seconds
.... <u>ARCA:</u>
........ OS Confirm: ............... 0.047 seconds
........ Market Confirm: ......... 0.205 seconds
........ OS Cancel Confirm: .... 0.015 seconds
........ Market Cancel Confirm: 0.192 seconds
*************************
<b>Broker C:</b>
.... <u>INET:</u>
........ OS Confirm: ............... 0.048 seconds
........ Market Confirm: ......... 0.048 seconds
........ OS Cancel Confirm: .... 0.015 seconds
........ Market Cancel Confirm: 0.015 seconds
.... <u>BRUT:</u>
........ OS Confirm: ............... 0.047 seconds
........ Market Confirm: ......... 0.047 seconds
........ OS Cancel Confirm: .... 0.016 seconds
........ Market Cancel Confirm: 0.016 seconds
.... <u>ARCA:</u>
........ OS Confirm: ............... 0.047 seconds
........ Market Confirm: ......... 0.047 seconds
........ OS Cancel Confirm: .... 0.016 seconds
........ Market Cancel Confirm: 0.016 seconds
*************************
Note: OS = Order Server, Market = the specific ECN
Each number shown is the average of ten orders placed through the specific broker to the specific route. As you can see, the speeds can vary considerably. For some trading styles, an extra 0.25 seconds may be insignificant and not affect results in the slightest. However, for other trading styles, the speed difference can be important.
Best of luck,
-Eric
Quote from Runningbear:
One way over overcoming false signals through bad ticks is by using some weighted calculation of price and vol across a specific time period. This won't eliminate them completely but will half the number of false signals.
I process price and volume off each tick but I look for a specific confirmed movement in the price volume information across a 5 or ten minute period, so one bad tick will change the calculation slighly but not nessesary trigger a false entry.
The funny thing is I didn't design it this way, I just noticed after examining false ticks on the chart - working with tick data has its advantages too.
Runningbear
Quote from stephencrowley:
How does one post calls on a millisecond timescale in the case of automated trading systems that make tens or hundreds of trades a day?
Quote from vlad:
Runningbear, thank you for the response. I have tested the tick-filtering procedure like you described. The funny thing is I didnât design it this way too. The situation with the false ticks is not so simple. In the reality different data feeds give different real time values for bid, ask values and sizes, and last price action and volume. I will talk about it later.
The described here system does not fight possible false ticks, system accepts every tick as real one. I include all possible false ticks into a tick noise function. Better way when used system reveals robustness to known type of the tick noise. If you know this noise distribution, it is possible to calculate a possible system behavior with the predetermined confidence interval. Row count gives that system may be successful if the noise STD smaller than at least 0.2-0.4 target average range. That means, if system trades ES and constant noise is around 1-2 ticks, the system can be used for targets not smaller than 5 ticks.
-------------------------------
The noise function is the distribution of the tick divergence in size or value between two data feed sources. I found that more useful for the model development and testing a transfer noise function which is the distribution of differences in bar values (open, high, low, close prices, e.g. for 1 min bar) between real time received values by used trading platform and feeding broker database. For example, if I use IB and their API with my custom developed platform, like it or not, I am loosing 10-20% ESâs ticks. Nana trader, I am not sure you could find such function in TS2000i.Quote from Nana Trader:
What is tick noise function' I couldn't find such function in TS2000i.
Thank you for the advice. This idea will be hardly useful in 15-200 minutes trading timescale.Quote from Nana Trader:
how about coding that if price spikes up or down Unusal
X% in either direction, wait for X seconds to see it price
hold itself near that range, and then only initiate a new trade