Probador de Estrategias de MetaTrader 5 y MQL5 Cloud Network - página 28
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
Gracias Renat, tengo otra pregunta, tal vez se superponga con la pregunta de Andrei, la prioridad del proceso metatester.exe está configurada en "baja", lo cual es básicamente correcto, para no interferir con, por ejemplo, la escritura en Word, ¿es posible o se piensa configurar la prioridad del usuario para que sea baja durante el día cuando la gente trabaja, y completa por la noche?
De hecho, no es posible controlar absolutamente la carga de la CPU cuando un agente se está ejecutando.
Pero una prioridad más baja ayuda realmente cuando el usuario está usando el ordenador para otras tareas - en este caso se asignan menos recursos a los agentes de la nube (¡no cuando se ejecutan localmente!). En otras palabras, puedes trabajar en Wordboards sin demasiados problemas.
También hay una tabla de horarios para la computación en nube, donde se puede especificar la hora de desconexión de la red. Por ejemplo, durante las horas de trabajo de 08:00 a 17:00, los agentes pueden ser desconectados.
Aumentar la prioridad de baja a alta no tiene sentido porque cuando no hay tareas de nivel superior, todos los recursos irán a procesos con menor prioridad. Esto facilita que los agentes se hagan cargo automáticamente del 100% de la CPU.
Renat, por favor asesora, tengo dos terminales instalados y dos gestores funcionando. El procesador es de 4 núcleos y por tanto los agentes son 8.
Esto se hizo así porque la carga del procesador con un gestor en funcionamiento era insignificante, y con dos, ha aumentado.
¿Es posible hacerlo, y no hay conflictos en el trabajo de los gerentes de diferentes terminales y, lo que es más importante, una debilidad
en cuanto al mantenimiento de las estadísticas y la posibilidad de hacer trampas. Gracias de antemano.
¿Están los 8 agentes en la red de la nube?
En este caso basta con poner sólo 4 agentes. La cuestión es que 8 agentes pueden hacer menos tareas que 4 agentes. No hay que olvidar los costes fijos de cada agente (memoria, CPU, masa de hilos en funcionamiento, etc.).
ps: una piel (ordenador) se puede utilizar para coser 4 sombreros completos (agentes), puede coser 8 o incluso 16 con una degradación correspondiente del resultado
¿Están los 8 agentes en la red de la nube?
En este caso basta con poner sólo 4 agentes. La cuestión es que 8 agentes pueden realizar menos tareas que 4 agentes. No hay que olvidar los costes fijos de cada agente (memoria, CPU, masa de hilos en funcionamiento, etc.).
ps: de una piel (ordenador) se pueden hacer 4 sombreros completos (agentes), y se pueden hacer 8 o incluso 16 con la correspondiente degradación del resultado
No me corresponde confirmar las palabras de un profesional, pero lo sé por la práctica, es la más pura verdad, por eso era necesaria la calificación de los agentes.
Yo solía correr 24 agentes en una máquina de doble núcleo, es cierto que se ahogan, mejor un agente por núcleo. Incluso 2 agentes por núcleo es un poco más lento.
No he accedido a MT5 desde hace mucho tiempo. Pero volví a hacer el búho. Ejecute la optimización y vea que los agentes de la nube están cargando el historial de años muy lejanos (1990, por ejemplo). La optimización se está realizando desde hace un mes. Entonces, ¿por qué los agentes se descargan tanta historia?
Cuando se ejecuta una prueba en cualquier sección de tiempo, el terminal necesariamente comprueba y sincroniza el historial disponible del servidor. Esto se hace debido a que casi cualquier comerciante, tarde o temprano, solicitará todo el historial disponible para las pruebas.
El terminal dará el historial a los agentes en la cantidad solicitada, pero no toda la profundidad disponible. Además, en el 99% de los casos, el historial de muchos corredores ya está almacenado en servidores distribuidos geográficamente de la red MQL5 Cloud Network, y desde ellos se entrega/sincroniza a los agentes.
Los agentes remotos también guardan enormes cachés de datos históricos para diferentes corredores, lo que les permite pasar instantáneamente la etapa de sincronización sin necesidad de descargar el historial.
Hemos creado un sistema informático distribuido muy eficiente y rentable. Para estimar la cantidad de datos transferidos durante la sincronización, mira los registros de los agentes (no en el terminal, sino en los archivos de registro de los agentes).
No consigo que un agente funcione en la columna de tráfico entrante/saliente y se obstina en mostrar 0kb y no aparece en la lista de agentes de la web.
Internet funciona a través del firewall en linux.
Has escrito en el primer post que gracias al SSL puede atravesar cualquier cortafuegos.
¿Tal vez debería especificar algunos ajustes de proxy y autorización en él?
o tal vez debería abrir algunos puertos en el firewall?
s.e. todo funciona bien en casa
aconsejar Renat
No puedo iniciar un agente en el trabajo en la columna con el tráfico entrante / saliente es obstinadamente 0kb y no aparece en la lista de agentes en el sitio web.
Internet funciona a través del firewall en linux.
Has escrito en el primer post que gracias al SSL puede atravesar cualquier cortafuegos.
¿Tal vez debería especificar alguna configuración de proxy y autorización enél?
o tal vez debería abrir algunos puertos en el firewall?
es decir, todo funciona bien en casa
¡Hola! Salieron resultados interesantes...
¡Hola! Salieron resultados interesantes...
¡todo está funcionando! Gracias.
Abrir, en el firewall de Linux, los umbrales 2000-2001 para el rango de direcciones 1 a 5.agentes.mql5.com ayudó.