Tiki en tiempo real - página 17
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
¿ESTÁ USTED SEGURO DE ESTO?
4 segundos ???? ¡No puede ser! ¿De verdad crees que el procesador se congeló durante 4 segundos o que la memoria se libera durante 4 segundos? ¿Estás bromeando?
Es más probable que sea la cola de escritura del disco.
El disco es más lento que la memoria y el procesador.
Y luego flush() , hay un comando de este tipo en el lenguaje C, probablemente usted sabe, se ejecuta cuando es conveniente y cómodo y puede ser ejecutado con algún retraso más a menudo relacionados con la carga del disco.
Eso es lo que se llama cuando los búferes necesitan ser restablecidos en el disco.
Bueno, no estoy tan seguro de ello, ya que no lo he comprobado experimentalmente en MT. Pero es una especie de estándar - lo que para en un registro hay tiempo de escritura en el disco, si el tiempo del evento, que causó esta escritura en un registro, es más importante, ¿no es lógico?
Y si asumimos, que el registro se escribe en el tiempo de escritura del disco, y si el disco está cargado, de todos modos tendrá un retraso en la grabación física, y el tiempo será el envío de un comando para escribir en el búfer de escritura.
Es decir, la descarga no cambia el búfer, sólo lo restablece un poco más tarde si hay un retraso.
wp. señaló correctamente que usted tiene que escribir el tiempo, porque en cualquier caso, sólo el tiempo que forma el propio terminal cuando se escribe en el registro, no tiene sentido orientar.
Bueno, no estoy tan seguro, porque no lo he comprobado experimentalmente en MT. Pero es algo estándar - ¿por qué en el registro la hora de la grabación en el disco, si es más importante la hora del evento, que causó esta grabación en la lógica?
Y si asumimos, que el registro se escribe en el tiempo de escritura del disco, y si el disco está cargado, de todos modos tendrá un retraso en la grabación física, y el tiempo será el envío de un comando para escribir en el búfer de escritura.
Es decir, la descarga no cambia el búfer, sólo lo restablece un poco más tarde si hay un retraso.
s.s. señaló correctamente que usted tiene que escribir el tiempo, porque en cualquier caso, sólo el tiempo que forma el propio terminal cuando se escribe en el registro, no tiene sentido orientar.
Supuse - que el tiempo se inserta justo antes de escribir en el disco, entonces todo encaja.
vamos a intentar describir el escenario paso a paso - para que quede más claro
1-El tic llegó (pulsar onTick) - debería imprimirse
2-Y OnTick imprime un registro - fue guardado con éxito
3-Este tick también llega a OnTick - también debe imprimirse.
4-Y aquí viene la pesadilla Windows lanza de repente 20 flujos de datos en el disco desde varios programas en este momento y bloquea temporalmente el disco -
El conductor ha puesto su cabeza de imán de datos en otro lugar -) y está escribiendo sus propios datos.
5-Esto es cuando el metatrader intenta enviar algo al DISCO
Pero el disco está terriblemente ocupado con el sistema operativo Windows - El sistema operativo le dice al metatrader sorry MQ tengo cosas más importantes que hacer - espera
6- Pasan 4 segundos.
7- y luego Windows después de 4 segundos - despejó la cola a la unidad - y dice a la MetaTrader - Estimado terminal de comercio - ¿quieres escribir algo en el disco? - ¡ok escríbelo!
8-metatrader escribe en el disco con un retraso de 4 segundos y registra la HORA no cuando quería escribir los datos en el disco - sino cuando realmente lo hizo.
De ahí vienen los 4 segundos.
---
Cualquier otro escenario, como que el terminal pusiera la hora local en el buffer - pero la escritura se retrasara 4 segundos - NO FUNCIONA tal escenario
si no, ¡el tiempo habría coincidido!
Bueno, no estoy tan seguro, porque no lo he comprobado experimentalmente en MT. Pero es algo estándar - por qué en el registro la hora de grabación en el disco, si es más importante la hora del evento, que causó esta grabación en el registro, es lógico, ¿no?
Y si asumimos, que el registro se escribe en el tiempo de escritura del disco, y si el disco está cargado, de todos modos tendrá un retraso en la grabación física, y el tiempo será el envío de un comando para escribir en el búfer de escritura.
Es decir, la descarga no cambia el búfer, sólo lo restablece un poco más tarde si hay un retraso.
s.s. ha señalado con razón que hay que escribir la hora, porque en todo caso, sólo el tiempo que el propio terminal genera al escribir en el registro, no tiene sentido centrarse en.
Y si no lo compruebas, entonces no despotriques.
¿Sabes siquiera de qué estamos hablando en este hilo?
Muéstrame la prueba, o si no vete de aquí.
Bueno, no estoy tan seguro, porque no lo he comprobado experimentalmente en MT. Pero es algo estándar - ¿por qué en el registro la hora de la grabación en el disco, si es más importante la hora del evento, que causó esta grabación en la lógica?
Y si asumimos, que el registro se escribe en el tiempo de escritura del disco, y si el disco está cargado, de todos modos tendrá un retraso en la grabación física, y el tiempo será el envío de un comando para escribir en el búfer de escritura.
Es decir, la descarga no cambia el búfer, sólo lo restablece un poco más tarde si hay un retraso.
s.s. señaló con razón que tiene que escribir el tiempo, porque en cualquier caso, sólo el tiempo que forma el propio terminal al escribir en el registro, guiado por ningún sentido.
¡Sólo en nuestro caso tenemos el tiempo para escribir en el disco!
Pero el tiempo se puede arreglar en el procedimiento GetTickDescription, le escribí al autor arriba.
Y si lo pusiera ahí, no habríamos discutido la posible causa del retraso en 4 segundos. En el registro lo más probable es que la hora local haya llegado igualmente para OnBock y OnTick, pero el tiempo en el disco habría sido 4 segundos diferente.
Y si no lo has comprobado, entonces no te preocupes.
¿Tienes idea de qué trata este hilo?
Muéstrame la prueba o lárgate de aquí.
No seas tan duro conmigo.
Es posible mejorar esta captura de garrapatas, fijarla para una o dos semanas, y tal vez sea posible captar el momento en que la fecha de registro se extienda con la fecha del evento.
Por supuesto, es posible acelerar este proceso cargando periódicamente un disco para la grabación.
Otra pregunta, la más importante. Por qué perder el tiempo en esta investigación :-))) cuál es el beneficio práctico.
---
Por el momento está claro que los ticks al principio vienen en OnTick y sólo entonces vienen en OnBuk, lo que es agradable es que OnBuk es llamado no sólo con los ticks, sino por ejemplo con los cambios de volúmenes en el mercado, en otras palabras, alguien abrió una orden, la cerró o la eliminó, los volúmenes han cambiado. Y es una información bastante importante para el mercado.
Y, por supuesto, siguiendo la lógica de las decisiones comerciales en el mercado de acciones / futuros lógicos para tomar exactamente en OnBuk, y no en OnTick.
Y si no lo has comprobado, entonces no te preocupes.
¿Tienes idea de qué trata este hilo?
Muéstrame la prueba, o si no lárgate de aquí.
Eres tú el que grita, gilipollas, 16 páginas no han pensado en cronometrar el evento antes de la Impresión y escribir la velocidad que miden, expertos, maldita sea).
Lo que tan orgullosamente me señalaste, dicen, no lo comprobé, ni siquiera entiendes realmente de lo que estoy hablando, apuesto. Pero es poco probable que lo entiendas.
Y el hecho de que este tiempo no es exactamente el tiempo de grabación en el disco, se comprueba.
Y si no lo has comprobado, entonces no te preocupes.
¿Tienes idea de qué trata este hilo?
Muéstrame la prueba o lárgate de aquí.
Qué te parece esto, listillo, muéstrame al menos una forma creíble de probar lo que pretendes, y me desentiendo y admito que no lo entiendo, si no, admite que tú mismo no lo entiendes, discúlpate o desentiéndete.
A saber: al menos una forma 100% fiable de verificar experimentalmente a qué hora escribe el terminal en el registro, es decir, las opciones principales:
1. La hora en que el terminal recibe el comando de impresión en la cola.
2. Hora de inicio del comando de impresión.
3. hora de finalización de la impresión en el buffer).
Esta variante puede ser la hora exacta:
4. tiempo de ejecución de la impresión en disco.
Qué te parece esto, listillo, me enseñas al menos una forma fiable de comprobar a dónde quieres llegar, y me desentiendo y admito que no lo he entendido, si no, admite que tú mismo no lo entiendes, discúlpate o desentiéndete.
A saber: al menos una forma 100% fiable de verificar experimentalmente a qué hora escribe el terminal en el registro, es decir, las opciones principales:
1. La hora en que el terminal recibe el comando de impresión en la cola.
2. Hora de inicio del comando de impresión.
3. hora de finalización de la impresión en el buffer).
Esta variante puede ser la hora exacta:
4. tiempo de ejecución de la impresión en disco.
Entonces, ¿qué sentido tiene?
Esperando su código...
Entonces, ¿cuál es el problema?
Esperando su código...
¿A qué código estás esperando? ¿Te he prometido algo? ¿Cuál era el precio?)
p/s/también tú no has entendido, como tu amigo, de qué estoy hablando.Mientras se desarrolla el debate, hice otro experimento.
Es decir, durante la inicialización lo cronometro en un microsegundo,
y antes de cada impresión, vuelvo a perforar el tiempo.
Lo ideal sería que fuera así
Pero muy a menudo resulta así (exposiciones de registro):
Así que la hora local se escribe en la impresión cuando se llama a la impresión.
Pero no encaja con 4 segundos...