MT5 For those who care about speed. - page 4
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
The server is pinged + the terminal's processing time.
Ping is the time it takes to transmit a request (packet of information) from the client to the server and back from the server to the client.
So, ping depends on amount of data transmitted, where each bit of information (source address, destination address, check bits and data packet) when transmitted from my computer to router via Ethernet at 10MHz takes 0.1 µs. That is, the transfer of 2 addresses and the receiver and the source takes 8 bytes or 64 bits, or 6.4 µs if the frequency of 1 MHz (which is also quite possible because the manufacturer writes from 1 to 10 MHz) time will be 64 µs. and in the reception of pings further 64 then will be 128 µs ... and information has not yet reached the internet ... and data in the package is not. Min data packet is something like 46 words...+ 4 words so the time can be 128 + 800 = 1528 µs. What is the real amount of data in the package is unknown. At reception=this time is spent again.
Also note that the concept of the system includes not only a metatradera software but also a user's computer, lines, modem, ISP, server, Expert Advisor and indicators.
Further, the server response time varies widely.
One more thing - the terminal program only works in flow, because Windows has many other tasks ...
The fact is that I've seen several times that the terminal did not respond over a minute at strong price movements.
The resume is as follows? You must imagine the physical process, think about the running time of the process and test the program on real data. By the way, the man is quite enlightening.
The fact is that I have observed several times that the terminal would not react for more than a minute when the price was moving strongly.
The resume is as follows? When you design a system and especially when you program it, you have to understand the physical process, think about the execution time of the process and test the program with real data.
Ping is the time it takes to send a request (packet of information) from client to server and back from server to client.
That is, ping depends on the amount of data transmitted, where each bit of information (source address, receiver address, control bits and data packet) in the transmission from my computer to the router via Ethernet at 10 MHz takes 0.1 µs. That is, the transfer of 2 addresses and the receiver and the source takes 8 bytes or 64 bits, or 6.4 µs if the frequency of 1 MHz (which is also quite possible because the manufacturer writes from 1 to 10 MHz) time will be 64 µs. and in the reception of pings further 64 then will be 128 µs ... and information has not yet reached the internet ... and data in the package is not. Min data packet is something like 46 words...+ 4 words so the time can be 128 + 800 = 1528 µs. What is the real amount of data in the package is unknown. At reception=this time is spent again.
Also note that the concept of the system includes not only a metatradera software but also a user's computer, lines, modem, ISP, server, Expert Advisor and indicators.
Further, the server response time varies widely.
One more thing - the terminal program only works in flow, because Windows has many other tasks ...
The fact is that I've seen several times that the terminal did not respond over a minute at strong price movements.
The resume is as follows? You must imagine the physical process, think about the running time of the process and test the program on real data. By the way, the man is quite enlightening.
Such claims need to be supported by evidence.
Do you have them?
Dear Renat, the whole comical thing is that when you buy a router or any other device such as a mouse, for example, the documentation specifies protocols such as:
4x LAN (10/100/1000 Mbps)
If you buy a sausage in accordance with Gosta, you can read e.g. the minimum meat content...
When buying Metatrader, no one can know what performance parameters you guarantee, because you do not guarantee anything ... not a single performance parameter, they simply do not exist ...
So technically you can not violate anything neither server response time nor speed of execution of trades or time of execution of commands...
Not only that, you even manage to conspire the protocol of exchange with the server ...
This is roughly equivalent to secreting the maximum travel interval of a bus or a train, or the composition of meat in a sausage.
Of course, program running time will be different for a 8-core processor and a single-core Atom, but it is possible to give paramen to some medium modification...
In terms of stock trading we still live in the Stone Age, so there are buyers of such programs and systems... Therefore, work is being done to standardize the network protocol FX API, in which the parameters of the protocol will be described and binding ...
the comical thing is that shelandr is working on the standardisation of the FX API network protocol in which the protocol parameters will be written down
that's right. you're reinventing yourselves. :)
FX has long been painted and standardized.
Learn the math, listen to people and take notes quietly. Don't talk yet, you look ridiculous.
Dear shelandr,
No one can guarantee the velocity of the endpoint device (other than detached marketers), as almost everything depends on:
Network latency is one of the biggest problems for traders. And no claim to TCP can be accepted. The solution is a close VPS/server hosting or generally moving execution to the broker's servers (if architecturally possible).
MetaTrader 4/5 platforms use geographically distributed access points (proxy servers), among which each terminal finds the fastest one and works with it. This allows to radically accelerate delivery of market data (ticks, charts, news) to each terminal.
In high frequency trading (HFT) it is very important to be able to send multiple transactions asynchronously as quickly as possible without wasting a fraction of a second on processing the result. This asynchronous trading method is fully available in MetaTrader 5 and dramatically reduces the average time required to send a batch of transactions.
Here the quality of technical queue chewing is in the hands of developers and usually every self-respecting company proudly publishes fabulous data on the speed of execution, implicitly substituting the concept of "overall speed of execution". Usually in such cases there is a story about extreme values of hundreds of thousands of transactions per second, about almost zero latency, etc.
Parsing your own queue of requests on the server is a primitive technical task. We are fine with this - the required tens of thousands of transactions per second are easily handled. If you need more, then performance can easily be increased (our brokers do not ask questions on this yet).
It is entirely at the broker's discretion when a trade order is taken out of the queue for execution.
From a technical point of view, delays are determined by network latency, gateway execution quality and the ultimate ECN/STP/Exchange execution system. On our side, the ECN/STP/Exchange execution gateways are implemented as productively as possible.
The only way for the end trader to accelerate is to reduce network latency by locating the execution system (trading terminal) as close as possible to the broker's trading servers.
At the current level of technical development, the choice of programming language and API has little effect on the speed of trade transaction generation on the client side. That said, MQL5 is a very, very fast programming language due to good compiler/optimizer and native 32/64 bit executable code generation, provides secure sandbox execution and offers a huge API (documentation over 3000 pages) to access the whole market environment.
Algorithmic trading systems like MetaTrader 5 with this level of integration and API capabilities are almost non-existent in the market.
That's more like it. You're reinventing yourselves. :)
Fix has long been painted and standardized.
Learn the math, listen to people and quietly take notes. Don't talk yet, you look ridiculous.
So why are we bickering? That's what I was asking...
Enter into the documentation words like:
The program of communication with the server implements the protocol (specify the link to the document, preferably in Russian, because we are on the Russian-speaking site). The data packet size is so much that words at a frequency of so-and-so and something else for the not particularly advanced... and all is well...
Performance parameters of the server, ask your dealer, he is aware of the case.
Sanks... Because I thought that you have a non-guaranteed velocity system - that is, for fans of guaranteed maximum latency is not recommended...
Enter into the documentation words like:
The program of communication with the server implements the protocol (specify the link to the document, preferably in Russian, because we are on a Russian-speaking site). The size of the data packet is so many words at a frequency of so-and-so and something else for the not particularly advanced... and that's it...
Holy naivety.
I recommend to think about protection of intellectual property rights, trade secrets, economics of products and others. Self-centredness reduces one's understanding of the world.
Dear shelandr,
1 From our side the ECN/STp/Exchange execution gateways are implemented as efficiently as possible.
2 For the end trader the only way to accelerate is to reduce network latency by placing the execution system (trading terminal) as close as possible to the broker's trading servers.
1 I wanted these parameters in the documentation.
2 You are absolutely right, in terms of programmer under Windows...but I already wrote, that Windows system is not intended for real-time systems and serves very different purposes and tasks...although some people manage to do for example watching HD video, which I use with pleasure and occasionally manage to distribute FulHD format to thousands of clients. A stock information is dust in comparison with it.
But usually, the rapid exchanges are implemented outside of Windows, such as Skype or mail client.
I don't want to have another OS, it's your choice ... I just want to be able to communicate with your server protocol and give me the opportunity to process the exchange information on the platform which I prefer and be able to control the connection and control the information which is pumped from my terminal, as well as WHAT and HOW the processor does my company.
This seems to me reasonable.