Skip to content
This repository has been archived by the owner on Feb 16, 2020. It is now read-only.

Fetch time slips - results in 2 candles generated simultaneously #195

Closed
djmuk opened this issue Feb 4, 2014 · 4 comments
Closed

Fetch time slips - results in 2 candles generated simultaneously #195

djmuk opened this issue Feb 4, 2014 · 4 comments

Comments

@djmuk
Copy link
Contributor

djmuk commented Feb 4, 2014

At least on my system the candle fetch / process / method loop takes just over 60 seconds (around 62), this means that the candle fetch time slips by 2 seconds a minute.
So what?
This means that every so often the process generates 2 consecutive candles simultaneously, as I am acting on 1 minute candles this can result in a significant delay in placing orders - Just now I had a fetch at 12:40:58 - so this generated the candle for 12:39, fetch at 12:42:00 which generated the candle for 12:40 and then a fetch at 12:43:02 which generated the candles for both 12:41 and 12:42...
Can we make the candle fetch interval <60 seconds (say around 50 secs) - if it is a prime number would it spread the fetches more evenly - how about 53?

@askmike
Copy link
Owner

askmike commented Feb 9, 2014

Gekko is not really architected for when you need that low resolution, so it might be that you'll notice other things as well.

The reason you are seeing that Gekko takes longer than 60 seconds is because of how Node works (Node only does something between ticks in the event loop). Instead of going for 60 / 53 / 50 seconds wouldn't it be better to always schedule the next fetch a couple of seconds over the minute? Problem with that would be that Gekkos everywhere will hammer the API at the same time and that if the exchange has a delay between executing trades and telling about them you still would not be able to finish the minutely candles.

For now you can lessen this number to 53/50 in a pull and I'll merge it in.


EDIT: Note that Gekko does not make any assumptions about whether trades happened in a specific minute or not. So imagine this scenario:

  • trade at 12:09:03
  • trade at 12:09:32
  • trade at 12:09:58
  • trade at 12:10:15

If a fetch at 12:10:05 only included the first 3 trades, Gekko cannot close that candle yet (and therefore calculate it completely and thus propagate), even though the system time says that the minute 12:09 is already closed. This is because at a number of exchanges the API is running behind the execution and if you would do a fetch at 12:10:03 you might not even get the 12:09:58 trade. Gekko won't make assumptions, but instead waits for the next trade so it knows for sure we have all trades from that minute. The consequence of this is that with the following trades:

  • trade at 12:11:03
  • trade at 12:11:32
  • trade at 12:11:58
  • trade at 12:14:15

The 12:11 candle would be calculated after the 12:14:15 is fetched. And at that point Gekko would also insert empty candles for 12:12 and 12:13. I don't know any solution for this, but this only effects you if trade on a small timescale on an exchange with low liquidity (which is very dangerous in itself in my opinion).

@djmuk
Copy link
Contributor Author

djmuk commented Feb 9, 2014

I would certainly not suggest gekko does it fetches on clockface intervals for exactly that problem of hitting the exchanges simultaneously. For now I have actually wound it back to 13 seconds so it fetches the trades to complete the candle as soon after the minute as possible. Perhaps it can be configurable in the candle manager section with a big "don't change this unless you know what you are doing"?

I hadn't thought about the problem of knowing when a candle was complete...

@askmike
Copy link
Owner

askmike commented Feb 12, 2014

Gekko now fetches every 48 seconds (0.8 minute).

@askmike
Copy link
Owner

askmike commented Jun 6, 2016

this is fixed!

@askmike askmike closed this as completed Jun 6, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants