MT5 and speed in action - page 44
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
More than once I've seen situations when Terminal loads the CPU 100% so much that it doesn't react to anything.
Then I looked at the logs and saw that there were wild skips of ticks in OnTick. However, if I correctly write an EA, this disastrous situation will not affect the trading results. I analyzed it specifically, everything is clear.
I wonder how widespread mechanisms for dealing with delays in Market Products are. I've never once seen any mention of machine power to run. Minimum ping is a yes.
Where were you launching them?
If on VPS for 2-5 dollars, then delays in tens and hundreds of milliseconds are easily caught in any hardly serious WinAPI function. Everything slows down starting from hypervisor level, turning a virtual machine into a slide show.
Explained above.
It is not GetMicrosecondsCount that is slowing down, it is the OS that is quantifying CPU resources for any thread in your strangled VPS. For any function, any action, any program inside your UPU.
Well, no CPU shell can slice and allocate resources fairly when it has 20 (that's still respectable) operating systems with 1500 threads of execution per copy. Take 8-16 cores and distribute them over 20 * 1,500 = 30,000 (thirty thousand physical tracks).
In my case (virtual box with vin7 + 2 cores + 16 GB of RAM on entirely my own hardware with nothing else running), where does periodic 2-3 µs come from?
Forum on trading, automated trading systems and trading strategy testing
MT5 and Speed in Combat
Andrey Khatimlianskii, 2020.10.05 10:19
Not really a UPU, but a virtual machine on rented hardware:
In my case (virtual box with win7 + 2 cores + 16GB of RAM on its own hardware with nothing else spinning), where does the periodic 2-3 µs come from?
That's the price of dual virtualisation.
Especially since VirtualBox is not a full-fledged Hyper-V type hypervisor, but lives on top of your current desktop operating system (Windows 7 also?) which has a CPU shell ground up for a different use case.
So, you have: Windows 7/10 -> VirtualBox -> Windows 7. Essentially, two levels of virtualization, with the first being unaware of VirtualBox's aspirations, seeing it as just a regular program. The CPU resource allocation(the threadsheduler) is clearly screwed up.
It should be: Hyper-V 2016/2019 -> Windows 2016/2019
It is not GetMicrosecondsCount that is slowing down, it is the OS that is quantifying CPU resources for any thread in your strangled VPS. For any function, any action, any program inside your UPU.
I think an argument like this will get you thinking. Advisor.
So far from slowing everything down. That's why I was able to change to winmm::timeBeginPeriod(1)+winmm::timeGetTime() quite harmlessly, getting speed like GetTickCount, but without the dreaded 16 ms limit. However, Market-producers are not allowed to do this, as it's a DLL. You're unlikely to make a millisecond regular version.
The MQL5 function to minimise all windows and the application itself is a great idea. We will work on that.
Here's another thing.
terminal on a VPS, then he will be strongly opposed to having everything abruptly rolled over. He can and should minimize windows himself if he leaves the RDP session.
Here is an example of what I wanted to say.
Both servers are different brokers, are in the same area, can be in the same location.
The service card suggests for AMP to be located in the UK.
And for Just for some reason offers in NL.
Why? If there is a closer vpc.
I think you'll find that's an argument that will get you thinking. Counsellor.
So far from slowing things down. That's why I was able to change to winmm::timeBeginPeriod(1)+winmm::timeGetTime() quite harmlessly, getting speed like GetTickCount, but without the dreaded 16ms limit. However, Market-producers are not allowed to do this, as it's a DLL. It's unlikely you'll be doing a millisecond regular version.
Well you're a master of racing stress tests with no correlation or reasonableness control.
Of course microsecond metering requires resources to be able to measure intervals 1000 times smaller than a millisecond.
If you occasionally need to measure intervals extra accurately, then use microseconds. And it will cost you 0 microseconds.
If you're set up to call millions of times self-measurement, you're probably engaging in self-delusion.
On a stifled VPS, overclocking the system timer via timeBeginPeriod is risky. You'll just increase your CPU overhead:
Otherwise, the operating system would have long ago made GetTickCount/GetTickCount64 precise and rejoiced at free precision. But no, you will have to pay for the accuracy of this timer.
Here is an example of what I wanted to say.
Both servers are from different brokers, are in the same area, may be in the same location.
The service card suggests for AMP to be located in the UK.
And for Just for some reason offers in NL.
Why? If there is a PSTN closer.
We know geo-points of the servers, and here positions of broker servers build from GeoIP bases.
And it often happens that the information does not correspond to reality. Therefore we should never assume that the broker's position is accurate.
We will look into this in more detail tomorrow, because we need to manually double-check and re-scan everything to answer the question.
That's the price of dual virtualisation.
Especially since VirtualBox is not a full Hyper-V type hypervisor, but lives on top of your current desktop operating system (Windows 7 as well?) which has a CPU shell tailored for a different use case.
So, you have: Windows 7/10 -> VirtualBox -> Windows 7. Essentially, two levels of virtualization, with the first being unaware of VirtualBox's aspirations, seeing it as just a regular program. The CPU resource allocation(the threadsheduler) is clearly screwed up.
It should be: Hyper-V 2016/2019 -> Windows 2016/2019
No, I've got virtualisers spinning around on my CentOS. But I'm not competent to continue this dialogue.