![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
But I look at the log, and the log shows the same tick with a difference of 4 seconds.
p.s.
I hate the phrase "it can't be", I've gotten used to the idea that anything can happen.
By the way, perhaps it is far from the subject, but once on the claim that the earth is round also said something like this - "it can not be.
In general I am always in doubt until I check then double-check, and preferably someone else double-checks a few times.
Are you sure you don't screw up the code that generates the log and processes the data? It's a 4 second difference.
Ticks are already in the terminal, i.e. they have already been sent over the network.
Put the code in the public domain
And see for yourself.
The tics are already in the terminal, i.e. they have already been transmitted over the network.
Put the open access code in it
And see for yourself.
Thanks, I'll give it a try, I've been following the topic for a long time, I'm more interested as a researcher.
this code lagged for 4 seconds ?
It doesn't seem to be this one.
don't see OnTick in the code
Apparently this was the code in question
Added my time to the code.
I remember the time when OnTick() was triggered(t_time = GetMicrosecondCount();)
Then I take time, when each function is executed
The result is
I.e. running time of each function is less than 50 microseconds!
Where can 4 seconds come from?
I think two EAs were running in one terminal and the terminal simply does not have time to
It simply has no time to "merge" all the information into one log so it sets the local time as it considers necessary.
In trading, personally, I use asynchronous orders.
The thing is (if you trade seriously on the Exchange), you need all the changes in the stock market,
and the sooner this event comes - the better.
I, for myself, see no alternative to OnBook
In principle, it is possible to relieve the direct invocation of trade operations from OnBook. All you need to do in OnBook is to form a flag to execute the operation and process the flag itself elsewhere. That is, the operation itself should be started in another procedure by the flag formed, which will create an event, but after leaving the procedure HeBook, and then the code OnBook itself will be free of heavy operations. However, if the orders are opened asynchronously, and there is no insanely large processing of conditions, it is unlikely to cause significant delays.
Added my time to the code.
I remember the time when OnTick() was triggered(t_time = GetMicrosecondCount();)
Then I take time, when each function is executed
The result is
I.e. running time of each function is less than 50 microseconds!
Where can 4 seconds come from?
I think two EAs were running in one terminal and the terminal simply does not have time to
The terminal simply has no time to "dump" all the information into one log file and that's why it sets local time as it thinks necessary.
I guess it's true, such a wild lag is not realistic.
1 - FLUSH has worked when MQ decided it himself!
2 - Technical delay in writing to disk due to intensive work on the hard disk
It is possible that there is already a write queue on your local machine - which is quite real, I had the experience of several terabytes of backup being poured onto the disk
I can only assume the following:
I've had several terabytes of backup fetched to the disk, e.g. if I ran Microsoft office, updated my Windows and recorded movies from the Internet, or if I worked with MS SQL on the local machine at the same time,
do a couple of backups, have a dozen 4 torrents and two or three dozen programs intensely write to disk.
i.e. i mean that if there was intensive work with the disk - it is possible and there was a delay in writing the log to disk.
Probably true, not realistic with such a wild delay.
1 - FLUSH worked when MQ decided this on its own!
2 - Technical delay in writing to disk caused by intensive work on the hard disk.
It is possible that some queue is already on your local machine for logging - which is quite real, I had the experience of several terabytes of backup being poured onto the disk
I can only assume the following:
I've had several terabytes of backup fetched to the disk, e.g. if I ran Mac irosoft office, updated my Windows and recorded movies from the Internet, or if I worked with MS SQL on the local machine at the same time,
do a couple of backups, have a dozen 4 torrents and two or three dozen programs intensively writing to disk.
I mean if there was intensive work with the disk - it is possible that there was a delay in logging to disk.
Added my time to the code.
I remember the time when OnTick() was triggered(t_time = GetMicrosecondCount();)
Then I take time, when each function is executed
The result is
I.e. running time of each function is less than 50 microseconds!
Where can 4 seconds come from?
I think two EAs were running in one terminal and the terminal simply does not have time to
"Therefore, it sets the local time as it considers necessary.
By the way - so that you don't get caught up in the logging time - you can add the local time to the array - which you form in the code - below
Then there will be a clear difference in the log between the time when the terminal reset the log to disk and the time when OnBook's tick or event arrived locally.
And this will be more correct from the research point of view.
Hardly connected with the disk, MT sets the time already when writing the log to its cache. That's what I thought the terminal in general for 4 seconds may be related to the overall system load, rather RAM and CPU.
ARE YOU SURE ABOUT THIS?
4 seconds ????, no way! Do you really think the processor froze for 4 seconds or memory was freed for 4 seconds?
It's more likely that it's the write queue on the disk.
The disk is slower than memory and the processor.
The flush() command is a C command, you probably know it and it is executed when it feels comfortable and can be delayed more often due to disk booting.
That's what they call it when you want to dump the buffers to disk.