You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
1434 - 1ms on average takes to get CopyTicks already uploaded 1000 ticks. Slow, it seems.
Requesting TRADE0tic with from_msc of the last tick received earlier. I get 3 ticks, but in 0.3 - 0.9ms! - Very slow now.
Strongly logged the code above and figured out the reasons. If CopyTicks (from > 0) gets ticks before the freshest one, it can skip some.
Regarding the original problem - that CopyTicks on the next call can give more ticks for the same period:
This is indeed the case. The problem is that exchange data streams bid/ask and flipper/volume are different streams, which are not synchronized with each other already on exchange side.
Because of this there are situations, when first comes bid/ask with time 12:12:12.300, and later comes flipper/volume with time 12:12:12.299.
Accordingly, requesting data since the last tick (12:12:12.300) you will not get a new flipper for 12:12:12.299.
PS. The terminal saves and sends ticks sorted by time. That is, time sequence of ticks given to CopyTicks is always increasing.
There are two streams of ticks receiving - INFO and TRADE. ALL is a synthesized union (seems to be on terminal side), that's why such mishaps may occur.
It's because of synthesized that there were such words
initial tick records after the call of CopyTicks will contain not zeros, but the current values of bid, ask and last at the requested moment of time
With the tape this problem should not arise with correct operation of CopyTicks.
I think, the Help will be very seriously supplemented.
You can add any overloads yourself.
Tested CopyTicks with COPY_TICKS_TRADE flag
No difference.
Tested CopyTicks with COPY_TICKS_TRADE flag
No difference.
Forum on trading, automated trading systems and strategy tester
Mysterious stock indicator
fxsaber, 2016.09.30 21:26
1434 - the problem has not been solved.
Strongly logged the code above and figured out the reasons. If CopyTicks (from > 0) gets ticks up to the freshest, it can skip some.
Example.
Requested ticks with from = 2016.09.29 11:05:55.564. Got three ticks in reply
Some time later I've requested the tick history from afar and got a tick, which CopyTicks missed before
Such a bug!
Seems to be some conflict of concurrent writing to and reading from the tick database.
The collected real-time tick history of the TRADE thread didn't contain a tick with time 2016.10.04 10:37:08.773, which appeared later in the history.
This is somewhat inconsistent with what I said above. The problems are not only with the synthesised ALL-flow, but also with the direct one - TRADE.
1434 is the same bug for TRADE-types. Reproducing advisor
1434 - 1ms on average takes to get CopyTicks already uploaded 1000 ticks. Slow, it seems.
Requesting TRADE0tic with from_msc of the last tick received earlier. I get 3 ticks, but in 0.3 - 0.9ms! - Very slow now.
Relevant! No way to speed it up?
I would like to take this opportunity to thank the developers for their work with CopyTicks!
I can not claim that CopyTicks works absolutely correctly, but I managed to work with the tape perfectly and to understand CopyTicks deeper.
Not to reinvent the wheel, you can see fine-tuned examples of writing tick indicators based on the tape here and here.