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
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 so (log exposures):
But it doesn't fit with 4 seconds...
oh, they finally figured out how to time it, progress!)
s.s. as a confirmation that the time is not exactly written to disk I'll give you a simple test, between operations in the Test are done some calculations, taking on average 7 microseconds.
At the same time we see that with the same time in microseconds prints are output in tens + such operations, and prints are outputted every microsecond. I think it all makes sense.
ap: if you put the first print right before the second, then the delta is already 0-1, so the Print is the longest in this chain.
Oh, they've finally figured out how to time it, progress!)
What's the matter with you, sir? Don't you have anything better to do?
That's where it all started!
Don't you, sir? Don't you have anything better to do?
This is where it all started!
Added by
Also, don't you know thatGetMicrosecondCount() has an error of up to 16 ms! :)
The function that gives microseconds, has an error of up to 16 milliseconds, i.e. the error is an order of magnitude higher than its name, well, well)) can you also confirm with a pruf?
A function that gives microseconds has an error of up to 16 milliseconds, i.e. an error that is an order of magnitude greater than its name, well, well)) can you also confirm with a pruff?
Got it wrong
Wrong
Well, kudos to you for admitting the error straight away ;)
The lag of 4 seconds is most likely true at some point the terminal got confused, it seems to happen when antivirus starts scanning etc. cases.
And 4 seconds means that Print is 4 seconds later in the log cache, not that OnBook came 4 seconds later (although I think it's possible depending on how the computer is loaded at the moment)
s.w. as Print goes to the queue first and from there to the log.Well, kudos to you for admitting the error straight away ;)
The 4 second lag is most likely true at some point the terminal got confused, it seems to happen when antivirus starts scanning etc. cases.
And 4 seconds exactly means that Print came 4 seconds later in the log cache, not that OnBook came 4 seconds later (although I think it's possible depending on how you load the computer at that moment)
s.w. as Print goes to the queue first and from there to the log.Yeah, it's possible.
And 4 seconds means exactly that Print came 4 seconds later in the log cache, not that OnBook came 4 seconds later (although I guess it's possible depending on how the computer is loaded at the time)
s.w. Print goes to the queue first and from there to the log.Well yeah, how about that?
One chart was running OnBook and the other OnTick.
56 ms difference between OnTick and OnBook
and the same difference in print :)
Right, how about this?
One chart was running OnBook and the other OnTick
56 ms difference between OnTick and OnBook
And the same difference in print :)
Again, I'm not exactly sure, as I'm sleepy and doubts are the lot of the experienced and wise).
But I think it's just elementary thatSymbol() eats time )))
so true test - check - I'm too lazy)
it's ulong glob. perm.
Again, I'm not sure, because I'm sleepy and doubts are the lot of the experienced and the wise).
But I think it's just elementary thatSymbol() chews up time )))
so true test - check - I'm too lazy)
it's ulong glob. perm.
:), good night
Again, I'm not sure, because I'm sleepy and doubts are the lot of the experienced and the wise).
But I think it's just elementary thatSymbol() chews up time )))
so true test - check - I'm too lazy)
it's ulong glob. perm.
Alternatively, to eliminate concerns that Symbol() eats time, let both handlers "feed" equally.