MT5 Para aqueles que se preocupam com a velocidade. - página 4
Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
O servidor é pingado + o tempo de processamento do terminal.
Ping é o tempo que leva a transmitir um pedido (pacote de informação) de cliente para servidor e de volta de servidor para cliente.
Assim, o ping depende da quantidade de dados transmitidos, onde cada bit de informação (endereço de origem, endereço de destino, bits de verificação e pacote de dados) quando transmitido do meu computador para o router via Ethernet a 10MHz leva 0,1 µs. Ou seja, a transferência de 2 endereços e o receptor e a fonte leva 8 bytes ou 64 bits, ou 6,4 µs se a frequência de 1 MHz (o que também é bastante possível porque o fabricante escreve de 1 a 10 MHz) o tempo será de 64 µs. e na recepção de pings mais 64 então será de 128 µs ... e a informação ainda não chegou à internet ... e os dados no pacote não estão. Min pacote de dados é algo como 46 palavras...+ 4 palavras para que o tempo possa ser 128 + 800 = 1528 µs. O que é a quantidade real de dados no pacote é desconhecido. Na recepção = este tempo é passado novamente.
Note-se também que o conceito do sistema inclui não só um software metatradera mas também um computador do utilizador, linhas, modem, ISP, servidor e perito e indicadores.
Além disso, o tempo de resposta do servidor varia muito.
Mais uma coisa - o programa terminal só funciona em fluxo, porque o Windows tem muitas outras tarefas ...
O facto é que já vi várias vezes que o terminal não respondeu durante um minuto a fortes movimentos de preços.
O currículo é o seguinte? Deve imaginar o processo físico, pensar no tempo de execução do processo e testar o programa em dados reais. A propósito, o homem é bastante esclarecedor.
O facto é que tenho observado várias vezes que o terminal não reagiria durante mais de um minuto quando o preço se movia fortemente.
O currículo é o seguinte? Ao conceber um sistema e especialmente ao programá-lo, é preciso compreender o processo físico, pensar no tempo de execução do processo e testar o programa com dados reais.
Ping é o tempo que leva para enviar um pedido (pacote de informação) de cliente para servidor e de volta de servidor para cliente.
Ou seja, o ping depende da quantidade de dados transmitidos, onde cada bit de informação (endereço de origem, endereço do receptor, bits de controlo e pacote de dados) na transmissão do meu computador para o router via Ethernet a 10 MHz leva 0,1 µs. Ou seja, a transferência de 2 endereços e o receptor e a fonte leva 8 bytes ou 64 bits, ou 6,4 µs se a frequência de 1 MHz (o que também é bastante possível porque o fabricante escreve de 1 a 10 MHz) o tempo será de 64 µs. e na recepção de pings mais 64 então será de 128 µs ... e a informação ainda não chegou à internet ... e os dados no pacote não estão. Min pacote de dados é algo como 46 palavras...+ 4 palavras para que o tempo possa ser 128 + 800 = 1528 µs. O que é a quantidade real de dados no pacote é desconhecido. Na recepção = este tempo é passado novamente.
Note-se também que o conceito do sistema inclui não só um software metatradera mas também um computador do utilizador, linhas, modem, ISP, servidor e perito e indicadores.
Além disso, o tempo de resposta do servidor varia muito.
Mais uma coisa - o programa terminal só funciona em fluxo, porque o Windows tem muitas outras tarefas ...
O facto é que já vi várias vezes que o terminal não respondeu durante um minuto a fortes movimentos de preços.
O currículo é o seguinte? Deve imaginar o processo físico, pensar no tempo de execução do processo e testar o programa em dados reais. A propósito, o homem é bastante esclarecedor.
Tais alegações precisam de ser apoiadas por provas.
Têm-nas?
Caro Renat, a coisa cómica é que quando se compra um router ou qualquer outro dispositivo como um rato, por exemplo, a documentação especifica protocolos tais como:
4x LAN (10/100/1000 Mbps)
Se comprar uma salsicha de acordo com a Gosta, pode ler, por exemplo, o conteúdo mínimo de carne...
Ao comprar Metatrader, ninguém pode saber que parâmetros de desempenho garante, porque não garante nada ... nem um único parâmetro de desempenho, eles simplesmente não existem ...
Assim, tecnicamente não pode violar nada nem o tempo de resposta do servidor nem a velocidade de execução de operações comerciais ou o tempo de execução de comandos ...
Não só isso, como consegue mesmo conspirar o protocolo de troca com o servidor ...
Isto equivale aproximadamente a secretar o intervalo máximo entre autocarros ou comboios, ou a composição da carne de uma salsicha.
Claro que o tempo de execução do programa será diferente para um processador de 8 núcleos e um Átomo de um só núcleo, mas é possível dar aos paraménios alguma modificação média...
Em termos de comércio de acções ainda vivemos na Idade da Pedra, por isso existem compradores de tais programas e sistemas... Portanto, está a ser feito um trabalho de normalização do protocolo de rede FX API, no qual os parâmetros do protocolo serão descritos e vinculativos ...
o cómico é que o shelandr está a trabalhar na normalização do protocolo de rede FX API, no qual os parâmetros do protocolo serão anotados
isso mesmo. estão a reinventar-se a si próprios. :)
O FX foi há muito pintado e estandardizado.
Aprenda a matemática, ouça as pessoas e tome notas calmamente. Não fale ainda, parece ridículo.
Caro Shelandr,
Ninguém pode garantir a velocidade do dispositivo de endpoint (a não ser os comerciantes independentes), uma vez que quase tudo depende:
A latência da rede é um dos maiores problemas para os comerciantes. E nenhuma reivindicação ao TCP pode ser aceite. A solução é um alojamento VPS/servidor próximo ou, em geral, uma execução em movimento para os servidores do corretor (se arquitectonicamente possível).
As plataformas MetaTrader 4/5 utilizam pontos de acesso geograficamente distribuídos (servidores proxy) entre os quais cada terminal encontra o mais rápido e trabalha com ele. Isto permite acelerar radicalmente a entrega de dados de mercado (carraças, gráficos, notícias) a cada terminal.
No comércio de alta frequência (HFT) é muito importante ser capaz de enviar múltiplas transacções de forma assíncrona o mais rapidamente possível sem desperdiçar uma fracção de segundo no processamento do resultado. Este método de comércio assíncrono está totalmente disponível no MetaTrader 5 e reduz drasticamente o tempo médio necessário para o envio de um lote de transacções.
Aqui a qualidade da mastigação técnica da fila está nas mãos dos criadores e, normalmente, todas as empresas que se respeitam a si próprias publicam orgulhosamente dados fabulosos sobre a velocidade de execução, substituindo implicitamente o conceito de "velocidade global de execução". Normalmente, nestes casos, há uma história sobre valores extremos de centenas de milhares de transacções por segundo, cerca de latência quase nula, etc.
A análise da sua própria fila de pedidos no servidor é uma tarefa técnica primitiva. Estamos bem com isto - as dezenas de milhares de transacções necessárias por segundo são facilmente manuseadas. Se precisar de mais, então o desempenho pode facilmente ser aumentado (os nossos corretores ainda não fazem perguntas sobre isto).
Fica inteiramente ao critério do corretor quando uma ordem de comércio é retirada da fila para execução.
De um ponto de vista técnico, os atrasos são determinados pela latência da rede, qualidade de execução da gateway e o sistema final de execução ECN/STP/Exchange. Do nosso lado, as portas de execução ECN/STP/Exchange são implementadas tão eficientemente quanto possível.
A única forma do comerciante final acelerar é reduzir a latência da rede através da localização do sistema de execução (terminal de negociação) o mais próximo possível dos servidores de negociação do corretor.
Ao nível actual de desenvolvimento técnico, a escolha da linguagem de programação e API tem pouco efeito na velocidade de geração de transacções comerciais do lado do cliente. Dito isto, MQL5 é uma linguagem de programação muito, muito rápida devido a um bom compilador/optimizador e geração de código executável de 32/64 bits nativo, fornece uma execução segura de sandbox e oferece uma enorme API (documentação de mais de 3000 páginas) para aceder a todo o ambiente do mercado.
Sistemas de comércio algorítmico como o MetaTrader 5 com este nível de integração e capacidades API são quase inexistentes no mercado.
É mais isso. Estão a reinventar-se a si próprios. :)
Ofix foi há muito pintado e estandardizado.
Aprenda a matemática, ouça as pessoas e tome notas calmamente. Não fale ainda, parece ridículo.
Então porque é que estamos a discutir? Era isso que eu estava a pedir...
Introduzir na documentação palavras como:
O programa de comunicação com o servidor implementa o protocolo (especificar o link para o documento, de preferência em russo, porque estamos no sítio de língua russa). O tamanho do pacote de dados é tanto que as palavras a uma frequência de mais ou menos e algo mais para os não particularmente avançados... e tudo está bem...
Parâmetros de desempenho do servidor, pergunte ao seu revendedor, ele está ciente do caso.
Sanks... Porque pensava que tinha um sistema de velocidade não garantido - ou seja, para ventiladores de latência máxima garantida não é recomendado...
Introduzir na documentação palavras como:
O programa de comunicação com o servidor implementa o protocolo (especificar a ligação ao documento, de preferência em russo, porque estamos num sítio de língua russa). O tamanho do pacote de dados é tantas palavras a uma frequência de mais ou menos e algo mais para os não particularmente avançados... e é só isso...
Santa ingenuidade.
Recomendo que se pense na protecção dos direitos de propriedade intelectual, segredos comerciais, economia de produtos e outros. A egocentricidade reduz a compreensão do mundo.
Caro Shelandr,
1 Do nosso lado, as portas de execução ECN/STp/Exchange são implementadas tão eficientemente quanto possível.
2 Para o comerciante final, a única forma de acelerar é reduzir a latência da rede colocando o sistema de execução (terminal de negociação) o mais próximo possível dos servidores de negociação do corretor.
1 Eu queria estes parâmetros na documentação.
2 Tem toda a razão, em termos de programador sob Windows...mas já escrevi, que o sistema Windows não se destina a sistemas em tempo real e serve objectivos e tarefas muito diferentes...embora algumas pessoas consigam fazer por exemplo ver vídeo HD, que eu uso com prazer e ocasionalmente consigo distribuir em formato FulHD a milhares de clientes. Uma informação de stock é pó em comparação com ela.
Mas normalmente, as trocas rápidas são implementadas fora do Windows, tais como o Skype ou o cliente de correio.
Não quero ter outro SO, a escolha é vossa... Só quero poder comunicar com o vosso protocolo de servidor e dar-me a oportunidade de processar a troca de informação na plataforma que prefiro e poder controlar a ligação e controlar a informação que é bombeada do meu terminal, bem como O QUE e COMO o processador faz a minha empresa.
Isto parece-me razoável.