Um minuto e meio de diferença entre a hora local e a hora do novo tick. O que fazer. - página 2
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
Existe um código fonte com comentários.
Sente-se preguiçoso para dar uma olhada? Ou há algo que eu não entendo?
Eu fiz. Eu tive a idéia sem o código. Não entendo porque você me aconselha:
Você precisa adicionar os instrumentos mais líquidos ao Market Watch.
Em seguida, acrescente camadas desses instrumentos.
E, quando OnBookEvent() aciona, copie 1 tick (último), haverá um tempo e imediatamente pegue o tempo local e compare.
Como seu método é melhor ?
Eu já dei uma olhada. Eu tive a idéia sem o código. Não entendo porque você me aconselha:
Por que seu método é melhor?
Porque é o certo!
Eu cometi um erro, não a hora local, mas a hora do servidor.
1. os bilhetes chegam ao terminal em pacotes.
2. Cada pacote subsequente pode conter carrapatos que não foram "empilhados" no pacote anterior, mas têm o mesmo tempo que o pacote anterior.
3. OnBookEvent() é acionado na chegada de qualquer tick (mudança de preço, volume), ou seja, cada tick. (você aciona um temporizador - já ruim).
4. Você usa o tempo do computador local, o que não é necessário!
Aqui está tudo o que você precisa para negociar (verifique os horários das sessões de negociação)
Adicionado por
Se você precisa de precisão de milissegundos, então este
Adicionado
Mas tudo isso não dará o resultado desejado (os limites do tempo de negociação) porque
pode não haver carrapatos em uma sessão de negociação, e o tempo não pára.
Suponhamos que alguém tenha retirado sua ordem pendente, o registro mudou,
há um sinal, mas há uma correlação "antiga" (o tempo não é o tempo atual).
O terminal não transmite o tempo exato do servidor.
Você não me entendeu. Vamos começar pelo início.
1) Em seu programa, você liga para TimeCurrent() e recebe a hora de chegada da última cotação para um dos símbolos selecionados no Market Watch.
Que sejam 18:00:00.
2) Com o próximo comando, você recebe a hora do último tique da SBER.
Que sejam 17:58:00
3) Um pouco de tempo passa e você solicita novamente a hora do último tick da SBER.
Que sejam 17:59:00
Note a pergunta: Você acha que está tudo bem às 18:00:00 da TimeCurrent() não saber sobre o tick com o tempo 17:59:00 ?
Você não me entendeu. Vamos começar pelo início.
1) Em seu programa, você liga para TimeCurrent() e recebe a hora de chegada da última cotação para um dos símbolos selecionados no Market Watch.
Que sejam 18:00:00.
2) Com o próximo comando, você recebe a hora do último tique da SBER.
Que sejam 17:58:00
3) Um pouco de tempo passa e você solicita novamente a hora do último tick da SBER.
Que sejam 17:59:00
Pergunta de atenção: Você acha que não há problema em não estar ciente às 18:00:00 horas pelo TimeCurrent() de um tick com a hora 17:59:00 ?
No código que citei você pode contabilizar todas as carrapatas (sem problemas)
O último código não usa TineCurrent() masTimeTradeServer() - desta vez só é necessário
para verificar o tick com uma precisão de um dia e pronto!
Vamos começar do início.
Em geral, o que você quer fazer, para descobrir?
Por que você começou a comparar a hora do carrapato com a hora local?
Qual é o propósito original?
Agora vou lhes mostrar como este problema se apresenta na prática. Eu redesenhei completamente o Expert Advisor. Tornei possível apanhar novos carrapatos no OnTimer, bem como no OnBookEvent.
Há 45 símbolos no Market Watch. A maioria deles não é líquida.
Aqui está o resultado da captura de novos carrapatos no OnBookEvent:
Ou seja, um novo tique foi pego às 18:50 no TimeCurrent para o símboloSNGR-3.19 com o horário de 18:41.
Em seguida, há medidas do horário local do computador no momento:
1) receber um novo tick, ou seja, no momento da última chamada do CopyTick (ou SymbolInfo, dependendo das configurações).
2) O momento da última chamada.
Então, neste caso o problema ocorreu porque a função get new só foi chamada em 10 minutos.... Isso porque o evento OnBookEvent para oSNGR-3.19 não foi gerado durante 10 minutos.
Talvez o terminal o tenha colocado na fila de eventos e de alguma forma tenha desaparecido desta fila. Não existem tais erros com o OnTimer. Sim, pode haver um carrapato com 20 segundos de atraso.
Qual é o seu propósito original?
Por que você precisa comparar os horários dos tee com a hora local?
Qual é o seu propósito original?
Por que você precisa comparar os horários dos carrapatos com a hora local?
Quero saber a demora máxima entre quando o tick ocorre no servidor e quando ele chega no terminal. E eu quero saber como minimizar este tempo.
Este conhecimento pode ser usado para escrever meu próprio testador. Você pode até mesmo pedir aos desenvolvedores que aumentem o atraso.
TimeCurrent() - o tempo do último tick por um símbolo será menor do que o tempo de atraso, por isso pode ser usado. Usar a hora local na primeira versão não foi uma boa idéia.
Quero saber a demora máxima entre quando um tick ocorre no servidor e quando ele chega ao terminal. E como minimizar este tempo.
Este conhecimento pode ser usado ao escrever meu próprio testador. E talvez eu possa até mesmo confundir os desenvolvedores com atrasos maiores.
Estou vendo. Continuar... Sem mim.
E para o resto do fórum
Pergunta de atenção: Você acha que é normal não ter conhecimento de um tick às 18:00:00 pela TimeCurrent() com um horário de 17:59:00 ?
Acho que a questão é discutível. Queremos que a seqüência de tick atenda pelo menos os seguintes critérios:
1. deve ser sequencial, ou seja, o tempo de cada tick subseqüente >= o tempo do tick anterior;
2. atualidade. Isto é, a hora do último tique de chegada é a mais próxima possível do momento atual;
Parece que o problema está no segundo ponto.
A argumentação do ponto 2 é a seguinte: eu quero que o tempo desde a geração do tick no servidor até o recebimento (lag) seja mínimo, para que eu possa processá-lo mais rapidamente do que outros e tomar uma decisão comercial. Mas se o atraso for o mesmo para todos os proponentes - então não há problema (tanto quanto eu entendo). Ou seja, o servidor do corretor tem o problema, mas todos estão em pé de igualdade. Se alguém recebeu a informação sobre o tique às 17:59:01, e eu não a recebi nem mesmo às 18:00 - este é o grande problema.
E aqui está a questão. Qual é o problema (e existe um)? No servidor do corretor, que não dá o tique (para todos) por muito tempo, ou no MT5, que não o recebe por muito tempo.