Multiple Time Frames with TALIB and Tulip

[fib0618]

I am glad it works for you. Did some tests in the past with volume based indicators also, but they did not outperform a traditional indicator like RSI during my tests.

E.g. taking T5mainasync strat, on whole year 2018 it makes a profit of +164%, ETHEUR: https://cloud.think5.de/gekko/backtests/...81231.html

With a direct RSI to MFI indicator replacement, the profits get lower using this strategy. Maybe you can get better results with MFI and new, adjusted tresholds.

Yes it is possible, but you will need to add some gekko core modifications. The problem is, that talib und tulip work async with their indicator calculations. So these calculations will either need proper callbacks or async/await patterns to work with the core without running into candle timing and race conditions.

I made some pull requests to target exactly this issue. You may have a look and pick what you need. You may also play with the Green Gekko fork, which has implemented this feature ready to go. In my own strategies I run 5 different candle sizes within one strategy on many different talib indicators for example.

Hi Mark,

I was just experimenting with Green Gekko recently and I noticed that when using the async features you have implemented, the batch size has to always be 1 to get accurate backtesting results.. I added a bunch of debug messages to see what's going on, and I guess as expected, when batch size is more than 1, you get a big batch of candles first, then a big batch of indicators results, etc.. which results in inaccurate tests..

However, with a batch size of 1, backtesting becomes really really slow, and attempting to use tools like brute force or gekko batcher will take forever to run..

Is there any way to avoid this slow down or a work around you can suggest?

Hey guys, did someone figure out and solution to improve the backtest speed (bottle neck is batch size 1)?
Many thanks.

[mark.sch]

Hey guys, did someone figure out and solution to improve the backtest speed (bottle neck is batch size 1)?
Many thanks.

The current Gekko implementation is affected by a problem called "stream backpressure" - due to the way streams are implemented in Gekko. It is a timing/race problem and occurs depending on (heavy) indicator usage and system speed. When the prob occurs, Gekko is eating up your memory and backtests results become random and faulty.

Currently a workaround is implemented in Green Gekko to avoid memory leak and faulty backtests, in file: /core/markets/backtest.js

if(!this.closed) {
   setTimeout(() => {
     this.get();
   }, 5);
 }

You may vary the setTimeout value from 1 to 10 depending on your system speed and strategy complexity. Lowering the value increases the backtest speed - but keep in mind to check the memory consumption of your gekko process to avoid false results.

Best way will be to fix the Gekko stream implementation by following the node.js best practices and kick any artificial delay: https://nodejs.org/es/docs/guides/backpr...n-streams/

[Genoveva]

The value of the setTimeout parameter can vary from 1 to 10 depending on the speed of the system and the complexity of the strategy. I read on software of this processor and there it was written that speed is very important sizzling-hot777.com . And so it says that if the speed is low, it is not very good. If I'm not mistaken that's exactly what happened. But if I were you, I'd check all the info.