Auto Trade with Open E Cry

Hello everyone,

If the entry condition is true on bar #1, the following order is sent:

Buy next bar open -1 limit;

Let's assume the open of bar #1 is 1166.00.
Therefore, the simulated order is buy @ 1165.00 limit.

Now, if the low of bar#1 is 1165.00 the simulated limit order fills and the MarketPosition=1.

Ok, that's how we're all use to simulated trading.

Obviously real world execution is a whole other thing.

Now, let's enable MC to do full automation with Open E Cry.
Okay, we're all configured and ready to go.

When condition=true on bar #1, the MC AT(auto-trader) sends a buy limit @ 1165.00 to Open E Cry.
Okay, no problems so far.
The low of bar#1 is 1165.00, but Open E Cry has not filled this limit yet (slippage).
Price then bounces a little and bar#2 opens at 1165.50.

MC AT recalculates using the open of bar#2 and cancels the 1165.00 limit and replaces it with a buy limit at 1164.50.

This is where the problem is.
The condition was true and the simulated limit requirement filled. Therefore I do not want MC AT to recalculate the entry price based on bar#2.

I realize there are risks involved here. If the ES runs higher and beyond the price at which I originally would have taken profits then I will have to manually cancel that working limit order at 1165.00
I'm perfectly okay with that because it's the correct calculation for my needs.

I did receive a contradicting response from MC support today.
They said regardless of Sync or Async mode, the MC AT will recalculate on the next bar if my real world position is not filled.

Later a different tech support person said otherwise and instructed me to use Async which is the original choice I made.

I have a suspicion that the Open E Cry datafeed could have something to do with some real world issues I experienced today. The main thing I see is that the open price of bar#1 using TS datafeed is not the same as bar#1 using Open E Cry datafeed.

Even a 1 tick differential of the open price can change a winning position in to a losing position.

Would anyone care to share their thoughts?

Thanks,
Joe

if INTRABARORDERGENERATION is enabled,

the signal is recalculated every tick.


if INTRABARORDERGENERATION is NOT enabled,

the signal is recalculated at the end of each bar (EOB).


At the end of each recalculation, the old order is canceled and a new order is submitted.

...
Would anyone care to share their thoughts?

Thanks,
Joe

It would help if you draw a flow chart of your logic...

if INTRABARORDERGENERATION is enabled,

the signal is recalculated every tick.


if INTRABARORDERGENERATION is NOT enabled,

the signal is recalculated at the end of each bar (EOB).


At the end of each recalculation, the old order is canceled and a new order is submitted.

Yes, I understand that.

But my problem is different.

Take two identical charts loaded with a strategy. Set one to full automation and one to simulation.
If you leave the full automation in Sync mode, the strategy could actually execute many bars later if the market takes off. If the simulation chart fills, that's the only price I would ever want to get filled at otherwise I'd cancel the other. Apparently Async handles that, but Sync does not.

I guess the bigger question now is on data feed reliability.

Today the opening bar price for my strategy was 1 tick higher on Open E Cry than TS. Believe it or not this 1 tick difference produced a win on the Open E Cry data feed and a loss on the TS data feed. It could have easily been the opposite.

From the same computer I ran TS and sent the signal directly to Open E Cry.
From the same computer I ran MultiCharts with Open E Cry data feed and sent the signal directly to Open E Cry.

The signal from MultiCharts arrived at Open E Cry 0.31 seconds earlier than the TS signal.

Does this mean the Open E Cry data was faster and therefore allowed MultiCharts to calculate the signal and transmit the order faster?

Or does this mean the data feed speeds are par with one another and MultiCharts was my edge?

But that still doesn't answer the question why the Open E Cry bar open price was a tick higher than the TS bar open price.

Has anyone else have experience in this area?

Thanks,
Joe

you have a plateful of issues here:
brokers, data feed, order logic, fill protocol, etc.,
I would suggest you break down your issues into individual cases,
and deal with them separately.

Focusing just on the data feed issues so far:

In a not completely exhaustive but yet pretty significant analysis of popular retail data feeds here a while back, we concluded that none led the other consistently by more than a tiny fraction of a second, and that any average differences were smaller than the average time it took to get an order in, and thus, below the threshold of easy exploitation, which is pretty much what we expected since that would be an obvious low-hanging fruit situation. That's not to say that you won't find something different depending on what exactly you're looking for - it's just to chime in with what we found here - I think there's a popular conception that this feed or that feed is "way faster" but most of them are in the same ball park most of the time on hardware and internet connections that are sufficient, with minor exceptions such as how things are handled under resource constraints or around news events.

Regarding two data feeds having different opening prices for a bar, much depends on what kind of bar you are talking about. If it's a time-based bar e.g. 5 minutes, this would typically be either a result of one feed using time stamps from the exchange (if not spot forex) and the other time stamping locally, resulting in different ticks being included in the 5 minutes, or a result of one feed having different bad tick filtering or correction tick incorporation policies. If it's spot forex, it's really a crap-shoot, in that there's no central exchange and each feed has different bank feeds, so it's truly expected that they won't have exactly the same data at any given time. If they're non-time-based bars, you can also introduce a starting point dependency e.g. if you're using X tick bars, and one feed filters out a bad tick earlier in the day and the other doesn't, that ripples throughout the whole rest of the day causing opens and closes to be different. Similarly, range bars or Renko etc. could be affected by a single bad tick being filtered out on one side and not the other.

Try creating a 1 tick chart on each side, and exporting that data to Excel so you can compare and see what's different about it. I think you'll probably be surprised how different they can be on a regular basis.

I guess the bigger question now is on data feed reliability.

Go to OEC forum for developers, search for ''volume'' or ''tick data'' and you will find suggestions by OEC engineers on how to receive unfiltered data in ticks from OEC.

Then suggest to TSS that MC's dll responsible for handling OEC data is slightly rewritten to receive those unfiltered data.

The OEC data being unreliable results from the fact that this data is being filtered nd OEC is not able to filter the data properly.

Regards