Tiki in real time - page 17
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
ARE YOU SURE ABOUT THIS?
4 seconds ???? No way! You really think the processor was frozen for 4 seconds or memory was freed for 4 seconds? Are you kidding?
It is more likely to be the write queue on the disk.
The disk is slower than memory and the processor.
And then flush() , there is such a command in C language, probably you know, it is executed when it is convenient and comfortable and can be executed with some delay more often related to disk loading.
That's what is called when the buffers need to be reset to disk.
Well, I'm not so sure about it, since I haven't checked it experimentally in MT. But it's kind of a standard - what for in a log there is time of writing to disk, if time of event, which caused this writing to a log, is more important, isn't it logical?
And if we assume, that the log is written to disk write time, and if the disk is loaded, anyway you will have a delay in the physical recording, and the time will be sending a command to write to the write buffer.
i.e. the flush doesn't change the buffer - it just resets it a bit later if there's a delay.
wp. rightly noted that you have to write the time, because in any case, only the time that forms the terminal itself when writing to the log, there is no point in orienting.
Well, I'm not so sure, because I did not experimentally check it in MT. But it's kind of standard - why in the log the time of recording to disk, if more important is the time of the event, which caused this recording to the log, it is logical, right?
And if we assume, that the log is written to disk write time, and if the disk is loaded, anyway you will have a delay in the physical recording, and the time will be sending a command to write to the write buffer.
i.e. the flush doesn't change the buffer - it just resets it a bit later if there's a delay.
s.s. rightly noted that you have to write the time, because in any case, only the time that forms the terminal itself when writing to the log, there is no point in orienting.
I assumed - that time is inserted just before writing to disk, then everything fits together.
let's try to describe the scenario step by step - to make it clearer
1-The tick came (hit onTick) - should be printed
2-And OnTick prints a log - it was successfully saved
3-This tick arrives at OnTick too - it should also be printed.
4-And here comes the nightmare Windows suddenly spews 20 data streams onto the disk from various programs at this moment and temporarily locks the disk -
The driver has put its data magnet head somewhere else -) and is writing its own data.
5-This is when the metatrader tries to send something to the DISK
But the disk is terribly busy with the Windows operating system - The operating system is telling the metatrader sorry MQ I have more important things to do - wait
6- 4 seconds go by.
7- and then Windows after 4 seconds - cleared the queue to the drive - and says to the MetaTrader - Dear trading terminal - you want to write something to disk? - ok write it!
8-metatrader writes to disk with a delay of 4 seconds and records the TIME in the log, not when it wanted to write data to disk - but when it actually did.
That's where the 4 seconds come from.
---
Any other scenario, such as the terminal put the local time in the buffer - but the write was delayed by 4 seconds - DOES NOT WORK such a scenario
otherwise the time would have coincided!
Well, I'm not so sure, because I did not experimentally check it in MT. But it's kind of standard - why in the log the time of recording to disk, if more important is the time of the event, which caused this recording to the log, logically?
And if we assume, that the log is written to disk write time, and if the disk is loaded, anyway you will have a delay in the physical recording, and the time will be sending a command to write to the write buffer.
i.e. the flush doesn't change the buffer - it just resets it a bit later if there's a delay.
s.s. rightly noted that you have to write the time, because in any case, only the time that the terminal itself generates when writing to the log, there is no point in focusing on.
And if you do not check, then do not bullshit rant.
Do you even know what we are talking about in this thread?
Show me the test, or else get out of here.
Well, I'm not so sure, because I did not experimentally check it in MT. But it's kind of standard - why in the log the time of recording to disk, if more important is the time of the event, which caused this recording to the log, logically?
And if we assume, that the log is written to disk write time, and if the disk is loaded, anyway you will have a delay in the physical recording, and the time will be sending a command to write to the write buffer.
i.e. the flush doesn't change the buffer - it just resets it a bit later if there's a delay.
s.s. rightly noted that you have to write the time, because in any case, only the time that forms the terminal itself when writing to the log, guided by no sense.
Just in our case we get the time to write to disk!
But the time can be arranged in the GetTickDescription procedure, I wrote about it to the author above.
And if he put it there, we would not have discussed possible cause of delay in 4 seconds. In the log most likely the local time would have come equally for OnBock and OnTick, but the time to disk would have been 4 seconds different.
And if you haven't checked it, then don't give a shit.
Do you have any idea what this thread is about?
Show me the test or get the fuck out of here.
Don't be so hard on me.
It is possible to improve this tick-catching, set it for a week or two, and maybe catch the moment when the date of recording in the log spreads with the date of the event.
Of course, it is possible to speed up this process periodically loading a disk for recording.
Another question, the most important . Why waste time on this research :-))) what is the practical benefit.
---
For the time being it is clear that ticks at first come in OnTick and only then they come in OnBuk, what is nice is that OnBuk is called not only with ticks but for example with changes of volumes at market, in other words someone opened an order, closed it or deleted it, the volumes have changed. And it is quite important information for market.
And of course following the logic of trading decisions in the market of stocks / futures logical to take exactly in OnBuk, and not in OnTick.
And if you haven't checked, then don't give a shit.
Do you have any idea what this thread is about?
Show me the test, or else get the fuck out of here.
You're the one yapping, dick, 16 pages haven't thought of timing the event before the Print and write the speed they measure, experts, damn it).
What you so proudly pointed out to me, like I did not check, but I'm saying, you yourself do not really understand what I'm talking about, I bet. But you are unlikely to understand it.
And the fact that this time is not exactly the time of recording to disk, it is checked.
And if you haven't checked, then don't give a shit.
Do you have any idea what this thread is about?
Show me the test or get the fuck out of here.
How about this, smart guy, show me at least one credible way to test what you're getting at, and I'll bail and admit that I didn't understand, otherwise admit that you don't understand yourself, apologize, or bail yourself out.
Namely - at least one 100% reliable way to experimentally verify exactly what time the terminal writes to the log, namely the main options:
1. the time the terminal receives the Print command in the queue.
2. time of Print command start.
3. time of termination of the print in the buffer.)
This variant may be the exact time:
4. time of print execution to disk.
How about this, smart guy, you show me at least one reliable way to check what you're getting at, and I'll bail and admit that I didn't understand, otherwise admit that you don't understand yourself, apologize, or bail yourself out.
Namely - at least one 100% reliable way to experimentally verify exactly what time the terminal writes to the log, namely the main options:
1. the time the terminal receives the Print command in the queue.
2. time of Print command start.
3. time of termination of the print in the buffer.)
This variant may be the exact time:
4. time of execution of the print to disk.
So, what's the point?
Waiting for your code...
So what's the deal?
Waiting for your code...
What code are you waiting for? Did I promise you something? What was the price again?)
p/s/ you too have not understood, like your friend, what I am talking about.While the debate is going on, I did another experiment.
I mean, during initialisation I time it by a microsecond,
and before each print, I drill the time again.
Ideally, it should be so
But very often it turns out this way (log exposures):
So local time is written to the print when the print is called.
But it doesn't fit with 4 seconds...