I've been wondering what kind of impact a large number of AlgoLab clients all placing orders for the same futures contract at the same price would have on their respective fills. I have not yet observed any clients missing trades due to other "competing" AlgoLab orders, for either the simulated accounts, or funded accounts, but I suppose the possibility is there. And if that were to happen, who would get filled first? And who would not get filled at all? If all of the virtual machine containers are firing orders out at exactly the same time, from the exact same physical location, at exactly the same price then I imagine who got filled and who didn't would be up to chance.
The futures markets that AlgoLab trades are typically "high volume" markets. For example, on March 7th, 2017, there were just over 1,400,000 contracts traded for the ES (S&P 500 futures emini) contract. The price range for that day was 10.75 points (from the high of the day to the low), so if each "tick" is worth .25, that would be a total of 43 different prices that the contract traded at during that particular day. This means, that on average (this is just a very ROUGH guess), 1,400,000 contracts / 43 prices = 32,558 trades conducted at each price through the day.
So when 100 AlgoLab customers all place orders to BUY an average of, say 2 contracts of ES at 2000.00 stop limit, that would be a total of 200 orders in that huge pack of 32,500 orders all wanting to get filled at 2000.000. Chances are good that every single AlgoLab client will get filled on that order. But maybe not... and there are certainly no guarantees.
So what I thought I would do is conduct a quick study and take a look at the performance metrics for one of AlgoLab's best systems "Triangles15" if the order entry stop limit orders were offset by 1 tick to 10 ticks, both before and after that actual "normal" price.
What I mean, is, if normally, a buy stop limit order is, say $2000, then 1 tick before would be to change that order to $1999.75 and 1 tick after would be to change that order to $2000.25 (The ES contract's minimum tick size if .25). In this study, I'll take a look at the total backtesting profit for every tick offset and see how many ticks offset starts to negatively effect the profit.
The idea is that if there is no significant difference between profits over a range of tick offset values, then it might make sense to randomize a tick offset value into AlgoLab so we aren't all placing orders at exactly the same price. For example, if there is a range of 5 ticks both before and after the "normal" entry price that doesn't produce any significant change in total profits, then that would be a total of 10 different entry prices that could be split up amongst all AlgoLab clients so that we aren't all competing for a fill at the same price (assuming this ever happens at all... and if so, it would probably be during over night, thinly traded sessions).
It would appear, that there is a gradual decline in the over all profit of the Triangles15 system when entries are offset by 5 ticks on either side of the original entry target (which would be at "0" ticks offset).
I believe the decline from 1 to 3 ticks is probably insignificant and could be simply due to the fact that the trading system parameters were optimized using 0 offset.
Further, it is interesting to note that the average trade size increases (which is a good thing!) when the offset is moved in the + direction.
Therefore, I would think that assigning the following tick offset values at random could be beneficial to ensure than not too many AlgoLab client trade orders are stacking up on top of each other:
-2, -1, 0, 1, 2, 3, 4
I added 2 additional offset values (+3 and +4) than negative because I think the reduction in total profit is offset by an increase in average trade profit.
Another reason why I think the reduction in profit as we move away from 0 offset is insignificant is because the Gain/Pain ratio stayed steady at 4% for all of the above values. Excpet, that +4 was actually was 1% LOWER at 3% (lower GP ratio is better). Gain/Pain metric is the maximum drawdown over the entire testing period divided by the maximum profit generated by the system. This is my favorite method of quantifying a system's performance, as the amount of profit that a system generates is less important than how much risk is assumed in order to generate that profit. Generally, the lower this Gain/Pain percentage, the BETTER the system performance is - that is, the lower this number is, the less risk is assumed per dollar of profit.