Mi enfoque. El núcleo es el motor. - página 147
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
En general, el problema está casi resuelto.
Me confunde el hecho de que, digamos que 5 EAs estarán transmitiendo la cantidad completa de paquetes de trabajo si el motor está funcionando con un sexto. A los otros cinco hay que prohibirles que transmitan información laboral por el momento. Que se limiten a "escuchar las ondas".
Estoy de acuerdo. Eso tiene sentido.
Así que funcionarán normalmente, pero no escribirán mensajes en el recurso. Sólo a una copia del núcleo de parámetros. Y cuando se conecte, escribirá el núcleo de parámetros en el recurso y el Motor lo cargará. Una vez conectado, el Asesor Experto comenzará a escribir mensajes para el Motor en el recurso de mensajes.
La pregunta es sobre la conexión.
El motor expone una pequeña dirección de cadena a todos los EAs. El núcleo del EA con la misma dirección de reconocimiento se recupera y el funcionamiento estándar del motor-asesor se inicia automáticamente. Cuando el motor cambia a otro EA, el motor cambia el núcleo del EA con el que estaba trabajando al estado de espera de dirección, al igual que los otros EAs en ese momento. En este punto, todos los EAs están desconectados y el motor está esperando la otra dirección del EA que el motor necesita.
El núcleo del nuevo EA responde y entra en el estado de funcionamiento estándar. La próxima vez el motor sigue enviando la línea de meta y el estado de espera no se cambia. Además del intercambio estándar, el Asesor Experto tiene que analizar un flujo para comprobar si el final de la línea de trabajo aparece en él. Al principio de los paquetes de intercambio debe haber una cadena que indique a quién va dirigido el paquete desde el motor. Ese núcleo recibe el paquete de control y comienza a enviar paquetes de su estado con la frecuencia especificada.
Los demás esperan que se les dirija a través de una cadena de identificación única para cada EA. Al cambiar, el motor envía al EA actual una cadena de fin de vida. El EA deja de enviar nada y entra en el estado de reconocimiento de su propia cadena de reconocimiento que es al mismo tiempo el inicio del trabajo estándar de intercambio con el motor.
La pregunta es sobre la conexión.
El motor expone una pequeña dirección de cadena a todos los EAs. El núcleo del EA con la misma dirección de reconocimiento se recupera y el funcionamiento estándar del motor-asesor se inicia automáticamente. Cuando el motor cambia a otro EA, el motor cambia el núcleo del EA con el que estaba trabajando al estado de espera de dirección, al igual que los otros EAs en ese momento. En este punto, todos los EAs están desconectados y el motor está esperando la otra dirección del EA que el motor necesita.
El núcleo del nuevo EA responde y entra en el estado de funcionamiento estándar. La próxima vez el motor sigue enviando la línea de meta y el estado de espera no se cambia. Además del intercambio estándar, el Asesor Experto tiene que analizar un flujo para comprobar si el final de la línea de trabajo aparece en él. Al principio de los paquetes de intercambio debe haber una cadena que indique a quién va dirigido el paquete desde el motor. Ese núcleo recibe el paquete de control y comienza a enviar paquetes de su estado con la frecuencia especificada.
Los demás esperan que se les dirija a través de una cadena de identificación única para cada EA. Al cambiar, el motor envía al EA actual una cadena de fin de vida. El EA deja de enviar nada y entra en el estado de reconocimiento de su propia cadena de reconocimiento que es al mismo tiempo el inicio del trabajo estándar de intercambio con el motor.
Los recursos son algo más sencillos. No necesitas una dirección, sólo un nombre de recurso. Tienes un modelo más complicado. Es más sencillo.
El núcleo es simplemente una matriz de valores. Cada Asesor Experto escribirá en él los valores de los parámetros de sus elementos de la GUI. Cuando sea necesario, los EAs guardarán una copia de los parámetros del kernel en el recurso y el motor la leerá y redibujará la GUI.
En principio, es una tarea sencilla, pero hay muchos pequeños matices. Por ejemplo, mensajes sobre el inicio y el fin de la comunicación con el EA. Sólo hay que pensar en el formato.
Por cierto, he conseguido agilizar la comunicación y disminuir la lentitud. Sin embargo, aún no he descubierto la razón. Ocurre durante el redibujado, pero lo extraño es que el redibujado en sí no está frenando. Pero el redibujado cuando se comunica con el recurso es más lento. La razón aún no está clara.
Poner algún tipo de control de tiempo-coste. Así que puedes ver dónde se ralentiza. Y cómo evitarlo.
Tal vez lo hice un poco complicado. No sé cómo está organizado dentro de su motor. Sólo estaba usando la lógica.
Poner algún tipo de control de tiempo-coste. Así que puedes ver dónde se ralentiza. Y cómo evitarlo.
Tal vez lo hice un poco complicado. No sé cómo está organizado dentro de su motor. Sólo estaba usando la lógica.
La lógica te acercó al punto, y en general, lo entiendes correctamente.
Hoy intentaré llegar al fondo de las causas del frenado. Lo siguiente está claro: el redibujado en sí mismo no se ralentiza. La escritura y la lectura del recurso tampoco son lentas. Pero juntos conseguimos la lentitud.
Hay un control, ¿cuál es la duración de la operación? Deben realizarse de forma secuencial. El Asesor Experto los realiza, capturando datos y enviándolos al motor con una frecuencia de, por ejemplo, 30 ms. Cuando se envía un hilo al motor, ¿está listo para recibir? ¿O qué hace?
Comprobando todo ahora.
El motor a los 30ms lee el recurso del mensaje del EA, y el EA, a la misma frecuencia, lee el recurso del mensaje del motor. En la misma frecuencia, ambos escriben sus mensajes al otro (si hay algo que escribir). Todo esto no provoca ninguna ralentización. Además, el redibujado en sí mismo, no provoca el frenado.
Sin embargo, la ralentización aparece si hay una combinación de redibujado y escritura/lectura del recurso en el lado del motor. La causa de esto aún no está clara. Lo que se está haciendo.
Comprobando todo ahora.
El motor a los 30ms lee el recurso del mensaje del EA, y el EA, a la misma frecuencia, lee el recurso del mensaje del motor. En la misma frecuencia, ambos escriben sus mensajes al otro (si hay algo que escribir). Todo esto no provoca ninguna ralentización. Además, el redibujado en sí mismo, no provoca el frenado.
Sin embargo, la ralentización aparece si hay una combinación de redibujado y escritura/lectura del recurso en el lado del motor. La causa de esto aún no está clara. Comprobando.
Puede ser un desajuste: EA y motor, 1 - ambos se pasan el uno al otro, 2 - ambos reciben, sus ciclos OnTimer no están sincronizados. Esperando el momento de la sincronización aleatoria para trabajar normalmente. ¿Podría ser esta la razón?