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
Mas eu olho para o tronco, e o tronco mostra o mesmo tick com uma diferença de 4 segundos.
p.s.
Odeio a frase "não pode ser", já me acostumei à idéia de que tudo pode acontecer.
A propósito, talvez esteja longe do assunto, mas uma vez sobre a afirmação de que a terra é redonda também disse algo como isto - "não pode ser".
Em geral, estou sempre em dúvida até que eu verifique e, de preferência, outra pessoa verifique algumas vezes.
Você tem certeza de que não estraga o código que gera o registro e processa os dados? É uma diferença de 4 segundos.
As passagens já estão no terminal, ou seja, já foram enviadas através da rede.
Colocar o código no domínio público
E veja por si mesmo.
Os tiques já estão no terminal, ou seja, já foram transmitidos através da rede.
Colocar nele o código de acesso aberto
E veja por si mesmo.
Obrigado, vou tentar, tenho acompanhado o tema por muito tempo, estou mais interessado como pesquisador.
este código demorou 4 segundos ?
Não parece ser este aqui.
não veja OnTick no código
Aparentemente, este era o código em questão
Acrescentei meu tempo ao código.
Lembro-me do tempo em que OnTick() foi acionado(t_time = GetMicrosecondCount();)
Então eu levo tempo, quando cada função é executada
O resultado é
Isto é, o tempo de funcionamento de cada função é inferior a 50 microssegundos!
De onde podem vir 4 segundos?
Acho que dois EAs estavam funcionando em um terminal e o terminal simplesmente não tem tempo para
Ela simplesmente não tem tempo para "fundir" todas as informações em um único registro, de modo que fixa a hora local conforme considera necessário.
No comércio, pessoalmente, uso ordens assíncronas.
A questão é (se você negocia seriamente na Bolsa), você precisa de todas as mudanças no mercado de ações,
e quanto mais cedo este evento chegar - melhor.
Eu, por mim mesmo, não vejo alternativa ao OnBook
Em princípio, é possível aliviar a invocação direta de operações comerciais da OnBook. Tudo o que você precisa fazer no OnBook é formar uma bandeira para executar a operação e processar a própria bandeira em outro lugar. Ou seja, a própria operação deve ser iniciada em outro procedimento pela bandeira formada, que criará um evento, mas depois de sair do procedimento HeBook, e então o próprio código OnBook estará livre de operações pesadas. Entretanto, se as ordens forem abertas de forma assíncrona, e não houver um processamento insanamente grande das condições, é pouco provável que isso cause atrasos significativos.
Acrescentei meu tempo ao código.
Lembro-me do tempo em que OnTick() foi acionado(t_time = GetMicrosecondCount();)
Então eu levo tempo, quando cada função é executada
O resultado é
Isto é, o tempo de funcionamento de cada função é inferior a 50 microssegundos!
De onde podem vir 4 segundos?
Acho que dois EAs estavam funcionando em um terminal e o terminal simplesmente não tem tempo para
O terminal simplesmente não tem tempo para "despejar" todas as informações em um único arquivo de registro e é por isso que ele define a hora local como achar necessário.
Acho que é verdade, um atraso tão grande não é realista.
1 - A FLUSH trabalhou quando a própria MQ o decidiu!
2 - Atraso técnico na gravação em disco devido ao trabalho intensivo no disco rígido
É possível que já exista uma fila de gravação em sua máquina local - o que é bem real, eu tive a experiência de vários terabytes de backup sendo despejados no disco
Só posso assumir o seguinte:
Tive vários terabytes de backup buscados no disco, por exemplo, se eu executava o Microsoft Office, atualizava meu Windows e gravavava filmes da Internet, ou se eu trabalhava com MS SQL na máquina local ao mesmo tempo,
fazer um par de backups, ter uma dúzia de 4 torrents e duas ou três dúzias de programas gravados intensamente em disco.
ou seja, se houve um trabalho intensivo com o disco - é possível e houve um atraso na gravação do registro em disco.
Provavelmente é verdade, não é realista com um atraso tão grande.
1 - FLUSH funcionou quando a MQ decidiu isto por si só!
2 - Atraso técnico na gravação em disco causado por um trabalho intensivo no disco rígido.
É possível que alguma fila já esteja em sua máquina local para registro - o que é bem real, eu tive a experiência de vários terabytes de backup sendo despejados no disco
Só posso assumir o seguinte:
Tive vários terabytes de backup buscados no disco, por exemplo, se eu rodei o escritório Mac irosoft, atualizei meu Windows e gravei filmes da Internet, ou se eu trabalhei com MS SQL na máquina local ao mesmo tempo,
fazer um par de backups, ter uma dúzia de 4 torrents e duas ou três dúzias de programas gravados intensivamente em disco.
Se houvesse um trabalho intensivo com o disco - é possível que houvesse um atraso no registro em disco.
Acrescentei meu tempo ao código.
Lembro-me do tempo em que OnTick() foi acionado(t_time = GetMicrosecondCount();)
Então eu levo tempo, quando cada função é executada
O resultado é
Isto é, o tempo de funcionamento de cada função é inferior a 50 microssegundos!
De onde podem vir 4 segundos?
Acho que dois EAs estavam funcionando em um terminal e o terminal simplesmente não tem tempo para
"Por isso, ele estabelece a hora local como considerar necessário.
A propósito - para que você não fique preso no tempo de registro - você pode adicionar a hora local à matriz - que você forma no código - abaixo
Então haverá uma clara diferença no registro entre o momento em que o terminal reinicializa o registro em disco e o momento em que o OnBook's tick ou evento chegou localmente.
E isto será mais correto do ponto de vista da pesquisa.
Dificilmente conectado com o disco, a MT define o tempo já ao gravar o log em seu cache. Foi o que eu pensei que o terminal em geral por 4 segundos pode estar relacionado com a carga geral do sistema, mais propriamente RAM e CPU.
VOCÊ TEM CERTEZA DISSO?
4 segundos ????, de jeito nenhum! Você realmente acha que o processador congelou por 4 segundos ou a memória foi liberada por 4 segundos? Você está brincando?
É mais provável que seja a fila de gravação no disco.
O disco é mais lento que a memória e o processador.
O comando flush() é um comando C, você provavelmente o conhece e é executado quando se sente confortável e pode ser atrasado com mais freqüência devido à inicialização em disco.
É assim que eles chamam quando você quer despejar os amortecedores no disco.