Tiki em tempo real - página 17
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
VOCÊ TEM CERTEZA DISSO?
4 segundos ???? De jeito nenhum! Você realmente acha que o processador foi congelado 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.
E então, flush() , existe tal comando na linguagem C, provavelmente você sabe, ele é executado quando é conveniente e confortável e pode ser executado com algum atraso mais frequentemente relacionado ao carregamento do disco.
É o que se chama quando os amortecedores precisam ser reinicializados em disco.
Bem, não tenho tanta certeza sobre isso, já que não o verifiquei experimentalmente em MT. Mas é uma espécie de padrão - para que em um registro há tempo de escrita em disco, se o tempo do evento, que causou essa escrita em um registro, é mais importante, não é lógico?
E se assumirmos que o registro é gravado em tempo de gravação em disco, e se o disco for carregado, de qualquer forma você terá um atraso na gravação física, e o tempo estará enviando um comando de gravação para o buffer de gravação.
ou seja, o autoclismo não muda o tampão - ele apenas o reinicia um pouco mais tarde se houver um atraso.
wp. observou, com razão, que é preciso escrever o tempo, pois em qualquer caso, somente o tempo que forma o próprio terminal ao escrever para o registro, não há sentido em orientar.
Bem, não tenho tanta certeza, porque não o verifiquei experimentalmente em MT. Mas é uma espécie de padrão - por que no log o tempo de gravação em disco, se mais importante é a hora do evento, que causou esta gravação no log, logicamente?
E se assumirmos que o registro é gravado em tempo de gravação em disco, e se o disco for carregado, de qualquer forma você terá um atraso na gravação física, e o tempo estará enviando um comando de gravação para o buffer de gravação.
ou seja, o autoclismo não muda o tampão - ele apenas o reinicia um pouco mais tarde se houver um atraso.
s.s. notou, com razão, que você tem que escrever o tempo, porque em qualquer caso, somente o tempo que forma o próprio terminal ao escrever para o registro, não há sentido em se orientar.
Eu assumi - que o tempo é inserido pouco antes de escrever em disco, então tudo se encaixa.
vamos tentar descrever o cenário passo a passo - para torná-lo mais claro
1-Tick veio (clique emTick) - deve ser impresso
2-And OnTick imprime um log - ele foi salvo com sucesso
3- Este tick também chega à OnTick - ele também deve ser impresso.
4- E aqui vem o pesadelo do Windows de repente lança 20 fluxos de dados para o disco de vários programas neste momento e trava temporariamente o disco -
O motorista colocou sua cabeça magnética de dados em outro lugar -) e está escrevendo seus próprios dados.
5-Isso é quando o metatarrader tenta enviar algo para o DISK
Mas o disco está terrivelmente ocupado com o sistema operacional Windows - O sistema operacional está dizendo ao Metatrader que lamento MQ eu tenho coisas mais importantes a fazer - espere
6 a 4 segundos passam.
7- e depois Windows depois de 4 segundos - limpou a fila para a unidade - e diz ao MetaTrader - Caro terminal comercial - você quer escrever algo em disco? - ok, escreva-o!
8-metatrader escreve em disco com um atraso de 4 segundos e grava o TEMPO no registro, não quando queria gravar dados em disco - mas quando realmente o fez.
É de lá que vêm os 4 segundos.
---
Qualquer outro cenário, como o terminal coloca a hora local no buffer - mas a escrita foi atrasada em 4 segundos - NÃO TRABALHA tal cenário
caso contrário, o tempo teria coincidido!
Bem, não tenho tanta certeza, porque não o verifiquei experimentalmente em MT. Mas é uma espécie de padrão - por que no registro o tempo de gravação em disco, se mais importante é o tempo do evento, que causou esta gravação no registro, é lógico, certo?
E se assumirmos que o registro é gravado em tempo de gravação em disco, e se o disco for carregado, de qualquer forma você terá um atraso na gravação física, e o tempo estará enviando um comando de gravação para o buffer de gravação.
ou seja, o autoclismo não muda o tampão - ele apenas o reinicia um pouco mais tarde se houver um atraso.
s.s. observou, com razão, que você tem que escrever o tempo, porque em qualquer caso, apenas o tempo que o próprio terminal gera ao escrever para o registro, não há sentido em se concentrar.
E se você não verificar, então, não faça besteiras.
Você ao menos sabe do que estamos falando neste tópico?
Mostre-me o teste, ou então saia daqui.
Bem, não tenho tanta certeza, porque não o verifiquei experimentalmente em MT. Mas é uma espécie de padrão - por que no log o tempo de gravação em disco, se mais importante é a hora do evento, que causou esta gravação no log, logicamente?
E se assumirmos que o registro é gravado em tempo de gravação em disco, e se o disco for carregado, de qualquer forma você terá um atraso na gravação física, e o tempo estará enviando um comando de gravação para o buffer de gravação.
ou seja, o autoclismo não muda o tampão - ele apenas o reinicia um pouco mais tarde se houver um atraso.
s.s. notou, com razão, que você tem que escrever o tempo, porque em qualquer caso, apenas o tempo que forma o próprio terminal ao escrever para o registro, guiado por nenhum sentido.
Só no nosso caso, temos tempo para escrever em disco!
Mas o tempo pode ser arranjado no procedimento GetTickDescription, eu escrevi sobre isso ao autor acima.
E se ele o tivesse colocado lá, não teríamos discutido a possível causa do atraso em 4 segundos. No registro provavelmente a hora local teria chegado igualmente para OnBock e OnTick, mas o tempo de disco teria sido 4 segundos diferente.
E se você ainda não verificou, então não ligue para isso.
Você tem alguma idéia do que se trata este tópico?
Mostre-me o teste ou saia daqui para fora.
Não seja tão difícil para mim.
É possível melhorar esta captura de carrapatos, marcá-la para uma semana ou duas, e talvez seja possível pegar o momento em que a data da extração se espalhará com a data do evento.
Naturalmente, é possível acelerar este processo periodicamente carregando um disco para gravação.
Outra questão, a mais importante: por que perder tempo com esta pesquisa :-))) qual é o benefício prático.
---
Por enquanto é claro que os carrapatos no início vêm no OnTick e só depois vêm no OnBuk, o que é bom é que o OnBuk é chamado não só com carrapatos mas por exemplo com mudanças de volumes no mercado, em outras palavras alguém abriu um pedido, fechou-o ou deletou-o, os volumes mudaram. E é uma informação bastante importante para o mercado.
E, claro, seguindo a lógica das decisões comerciais no mercado de ações/futuros lógicos para tomar exatamente no OnBuk, e não no OnTick.
E se você ainda não verificou, então não se preocupe.
Você tem alguma idéia do que se trata este tópico?
Mostre-me o teste, ou então saia daqui para fora.
Você é o único a tagarelar, idiota, 16 páginas que ainda não pensou em cronometrar o evento antes da impressão e escrever a velocidade que eles medem, especialistas, caramba).
O que você me apontou com tanto orgulho, como se eu não tivesse verificado, mas estou dizendo, você mesmo não entendeu realmente do que estou falando, aposto. Mas é improvável que você o entenda.
E o fato de que desta vez não é exatamente o momento da gravação em disco, ele é verificado.
E se você ainda não verificou, então não se preocupe.
Você tem alguma idéia do que se trata este tópico?
Mostre-me o teste ou saia daqui para fora.
Que tal isso, cara esperto, mostre-me pelo menos uma maneira confiável de testar onde você quer chegar, e eu me safo e admito que não entendo, caso contrário, admita que você não se entende, peça desculpas ou saia em liberdade.
Nomeadamente - pelo menos uma maneira 100% confiável de verificar experimentalmente a que horas o terminal escreve no registro, ou seja, as principais opções:
1. o momento em que o terminal recebe o comando Print na fila.
2. Hora de início do comando de impressão.
3. hora do término da impressão no buffer).
Esta variante pode ser a hora exata:
4. Tempo de execução de impressão em disco.
Que tal isso, cara esperto, você me mostra pelo menos uma maneira confiável de verificar onde você quer chegar, e eu me safo e admito que não entendi, caso contrário, admito que você não se entendeu, pede desculpas ou se safa.
Nomeadamente - pelo menos uma maneira 100% confiável de verificar experimentalmente a que horas o terminal escreve no registro, ou seja, as principais opções:
1. o momento em que o terminal recebe o comando Print na fila.
2. Hora de início do comando de impressão.
3. hora do término da impressão no buffer).
Esta variante pode ser a hora exata:
4. O tempo de execução da impressão em disco.
Então, qual é o objetivo?
À espera do seu código...
Então, qual é o acordo?
À espera do seu código...
De que código você está esperando? Eu lhe prometi alguma coisa? Qual era o preço novamente?)
p/s/ você também não entendeu, como seu amigo, do que estou falando.Enquanto o debate continua, fiz outra experiência.
Quero dizer, durante a inicialização, eu a cronometro por um microssegundo,
e antes de cada impressão, eu furo novamente o tempo.
Idealmente, deveria ser assim
Mas muitas vezes acontece assim (exposições de troncos):
Assim, a hora local é escrita para a impressão quando a impressão é chamada.
Mas não cabe com 4 segundos...