Multiple runs of same strategy

All posts which do not fit into any other sections of the forum.

Moderator: admin

Multiple runs of same strategy

Postby Loggy48 » Tue Sep 19, 2017 2:09 pm

I am trying to run two instances of a strategy that displays a different name in the strategy dashboard on TS2, and of course on Marketscope. These are the same strategy filename but with different settings run on the same currency and in the same time frame. I use different signature strings for the two instantiations so that the QTXT etc table entries can be separated in the Async callback in theory.

But I don't get any trade events passed back on closure of a position to either instantiation so while trades can be opened, I can't see what the outcome is. Order events are fine and TS opens a position anyway without reporting a trade event.

Will MS/TS (a) call back all running strategies in the same user, (b) just the same strategy that may be run with different settings at the same time, or (c) can it be made to call the actual strategy that initiated the trade? I have been trying this in simulation mode.

If I run the strategy on its own, the trade event call back occurs OK but by running it more than once I can compare the results and there are other advantages if I want to run the same strategy on different currencies and/or instruments.
Loggy48
 
Posts: 89
Joined: Tue Jun 24, 2014 8:39 am
Location: Manchester, UK

Re: Multiple runs of same strategy

Postby Alexander.Gettinger » Tue Sep 19, 2017 2:54 pm

Perhaps your strategy can not distinguish own orders and orders of another copy. Can you attach a strategy?
Alexander.Gettinger
FXCodeBase: Confirmed User
 
Posts: 3785
Joined: Wed Mar 31, 2010 9:40 pm
Location: Russia, Omsk

Re: Multiple runs of same strategy

Postby Loggy48 » Tue Sep 19, 2017 7:28 pm

Thanks for your reply Alexander

The strategy only works on its own trades. That's not the problem. The tradeID should be enough but I also use the QTXT stored in the tables as well to be sure. Each instantiation of the strategy generates its own signature. The strategy can therefore alter stoploss/limits as required and the appropritate position is modified.

When a position is closed by something external to the strategy, (eg Stoploss, Limit, manual) the closed trades table is interrogated to see what the closing order ID is, which is compared to the the stoploss/limit order IDs to see which closed the position, or it assumes a manual/external system closure. But since no trade event is detected, I don't get the information at all.

The issue is that no TRADE_EVENT is detected in ExtAsyncOperationFinished by either instance of the strategy. ORDER_EVENTS, open, close, update and even delete (although I don't need that) all work.

I was asking what *should* happen in EAOF when a trade event occurs on an account - does TS know which strategy opened the trade, or which instance of a strategy or does it tell each strategy so the strategy can work out what has happened. The simplest I would have thought would be to hold the process ID of the initiating strategy and communicate only with that but I don't know whether that is what is done.
Loggy48
 
Posts: 89
Joined: Tue Jun 24, 2014 8:39 am
Location: Manchester, UK

Re: Multiple runs of same strategy

Postby Alexey.Pechurin » Wed Sep 20, 2017 6:12 am

Hello Loggy48,

Have I understood your problem correctly? You have a strategy which subscribes for trading events for Orders and Trades tables. When a single instance of the strategy is running it receives all events. But when two instances are running they do not receive trade events? Am I right?

I have prepared and tested a simple sample. I have started two instances of the strategy and closed manually a position. Both instances received the same events including Trades table events. Can you try it?

does TS know which strategy opened the trade, or which instance of a strategy or does it tell each strategy so the strategy can work out what has happened.


TS notifies all strategy instances with all table events which it subscribed. It does not take into account who created a trade or closed it.

Alexey
Attachments
log_trade_events_s.lua
(801 Bytes) Downloaded 870 times
Alexey.Pechurin
 
Posts: 98
Joined: Sun Jul 22, 2012 11:26 pm

[SOLVED] Re: Multiple runs of same strategy

Postby Loggy48 » Wed Sep 20, 2017 6:43 am

Alexander

My bad - I was checking the closed trades table for trade.QTXT rather than trade.OQTXT so I never got a match. :oops:

But adding trace coding, at least I know now that all instantiations are called back!
Loggy48
 
Posts: 89
Joined: Tue Jun 24, 2014 8:39 am
Location: Manchester, UK

Re: Multiple runs of same strategy

Postby Loggy48 » Wed Sep 20, 2017 2:05 pm

Alexander - thanks for that.

I tried it in simulation mode by I don't see any offers, just trades and orders (which my running strategy also reports of course).

I now need to update my production strategy as I forgot to check an order update QTXT (I change the stoploss and limit manually sometimes).

Why is checking the trade or order ID not sufficient to define the trade?
Loggy48
 
Posts: 89
Joined: Tue Jun 24, 2014 8:39 am
Location: Manchester, UK

Re: Multiple runs of same strategy

Postby Alexey.Pechurin » Thu Sep 21, 2017 7:52 am

Why is checking the trade or order ID not sufficient to define the trade?


Usually we need to use QTXT to handle strategy restarting. If an id is stored in a strategy variable it will be reset after restart. So the strategy cannot determine its own trades and orders.

But probably I didn't understand your question properly, did I?
Alexey.Pechurin
 
Posts: 98
Joined: Sun Jul 22, 2012 11:26 pm

Re: Multiple runs of same strategy

Postby Loggy48 » Thu Sep 21, 2017 9:41 am

Alexey

That makes sense as restarting a strategy will re-initialise all variables. While the strategy is running the tradeID etc can be held in a strategy Lua table. It is probably worth coding in a periodic dump to SQLite that can be reloaded but at the moment I'm not doing that.

But the requestID, tradeID, orderID, offerID are all set by the system and must be unique across the system (and obviously the user). Because of that I had assumed that while the async call back may not know which instance of a strategy opened the trade, the tradeID should be sufficient to identify whether the trade was initiated by that particular instance. But it seems not and I have now added QTXT/OQTXT checks which are working.

Another issue I have is detecting the end of trading. I want to ensure that a trade closes on Friday ay 4.59pm New York time so when a trade opens, I set a target date by:

Code: Select all
   TargetDate = 6+7*math.floor(OpenDate/7)+1019.0/1440.0


(1700h is 1020 minutes)

then check the current time at each tick against TargetDate. My server is set to NY time but I never manage to close a trade that way. This was particularly annoying a couple of weeks ago when a trade was about 123 pips up and it didn't close!

It's a pity that system down is not available in one of the tables or at least to be able to set a future CloseDate in the trades table.
Loggy48
 
Posts: 89
Joined: Tue Jun 24, 2014 8:39 am
Location: Manchester, UK

Re: Multiple runs of same strategy

Postby Alexey.Pechurin » Fri Sep 22, 2017 2:25 am

But the requestID, tradeID, orderID, offerID are all set by the system and must be unique across the system (and obviously the user).


They are unique actually. May you describe detailed your problem when you use them without QTXT?

Another issue I have is detecting the end of trading.


I guess you can try to set a timer (host:execute("setTimer", ...)) which will notify your callback, for example once a minute. In the handler you can check the current time and close trades if it near the end of trading.
Alexey.Pechurin
 
Posts: 98
Joined: Sun Jul 22, 2012 11:26 pm

Re: Multiple runs of same strategy

Postby Loggy48 » Fri Sep 22, 2017 6:54 pm

Alexey -

If I don't check QTXT when there are 2 strategies running, the callback will always go to one of the strategies which may try to close the position or update a stoploss even though it also checks the trade or order ID as appropriate. The other strategy receives the callback as well but if it also tries to close the position, an error is reported because the close has already been initiated. The strategy (at the moment) only handles a single trade so the position is either closed, closing, opening or open and this flag is changed as soon as the order to close or update is executed.

On the timer issue, the only way setTimer could help is to ensure that something happens in the last minute (or few seconds) if there is no tick, or if the timeframe is too long (1H for example). At the moment I am using m1 timeframe.

This evening my strategy tried to close a position at 16:59:00, with a message

Market is closed. Any trading functionality is not available.

leaving it open at -7.6 pips. It appears that the market was closed early.

This could be where setTimer is useful by setting a callback at a given number of seconds from (say) an earlier event (calculated). Interesting. I'm really surprised the system couldn't process an order in the last minute. The error was also reported at 16:59:00, ie immediately the order was sent.

But at least it tried OK. :)
Loggy48
 
Posts: 89
Joined: Tue Jun 24, 2014 8:39 am
Location: Manchester, UK


Return to General Discussions

Who is online

Users browsing this forum: Google [Bot] and 7 guests