Milagros con el probador. - página 3

Nuevo comentario
 
notused:
Los resultados de los pases no coinciden para la optimización y el pase único (service-desk - #329165 + EA en el mismo lugar)
Vamos a resolverlo.
 
notused:
Los resultados de la optimización y del pase único no coinciden (service-desk - #329165 + EA allí también)
¿Construir 619? Este problema también ha comenzado a producirse. Pero no siempre. A veces los resultados son incluso los mismos, es decir, no se ha realizado ninguna optimización nueva, pero los resultados de las pruebas son de alguna manera diferentes. Por ejemplo, el beneficio final del gráfico difiere del de la lista. Después de un tiempo todo se restablece. Nunca había notado esto antes de la compilación 619 .
 
tol64:
¿Construir 619? El mismo problema ha comenzado a producirse. Pero no siempre. A veces los resultados son incluso los mismos, es decir, no he realizado ninguna optimización nueva, pero obtengo resultados diferentes durante las pruebas por alguna razón. Por ejemplo, el beneficio final del gráfico difiere del de la lista. Después de un tiempo todo se restablece. Nunca había notado esto antes de la compilación 619 .
La build 607 (aún no se ha actualizado al nuevo FIBO). Tal vez el problema está en la multidivisa y el temporizador (no se utiliza OnTick()), pero no estoy seguro.
 
notused:
La compilación sigue siendo 607 (aún no se ha actualizado al nuevo FIBO). Quizás el problema sea la multidivisa y el temporizador (no se usa OnTick()), pero no estoy seguro.
Entonces se elige con precisión el nombre de la rama. Milagros con el probador. )))
 

Algo está mal en la última versión del probador de estrategias. De repente (no del todo "de repente", sino después de la actualización a la compilación 619) el Asesor Experto prácticamente ha dejado de probar (lo mismo que en la aplicación #329165) - la memoria comenzó a ser consumida inmensamente (el modo "Todos los ticks" durante 5 años):

La última columna es "Tamaño de la máquina virtual". Como puedes ver tengo 4 núcleos + 4 agentes locales "remotos" (siempre han funcionado bien).

Al mismo tiempo, el sistema comienza a lagear muy mal (sí, 4GB de RAM + 16GB dedicados para PageFile) y la velocidad de optimización tiende al infinito. Como se puede ver, el tiempo de la CPU, prácticamente no se compromete.

Al mismo tiempo, hay errores en el registro:

Al parecer, esto se debe a la falta de memoria.

Presiono "stop" - la memoria no se libera inmediatamente. En 5 minutos desaparecieron los agentes locales, en otros dos minutos se liberó la memoria de los agentes remotos:

Sólo no está claro por qué un agente todavía tienen más de 100Mb colgar (no creo que tomó la nube - porque el tiempo de la CPU no se utiliza).

Bueno, yo desactivo los agentes locales "remotos". Nada cambia (los retrasos y errores del sistema).

Bueno, creo que el error está en mi Asesor Experto. Por lo tanto, empiezo a probar un ExpertMACD estándar, EURUSD, h12 de 2007.09.01 a 2012.03.26.

И... La misma situación: ralentizaciones, poco uso de la memoria (casi los mismos valores que en la primera imagen) + "no se puede inicializar el experto".

En ambos casos, algunos pases, sin embargo, tienen éxito.

Registro adjunto.

Líneas muy interesantes:

CJ      0       local4  17:42:32        USDNOK: history synchronization started
QL      0       Core 1  17:42:33        USDNOK: history synchronization started
RK      0       local4  17:43:49        USDNOK: history downloading completed
GL      0       Core 1  17:43:49        USDNOK: history downloading completed
NM      0       Core 1  17:43:49        USDNOK: history for 2006 year synchronized
QJ      0       local4  17:43:49        USDNOK: history for 2006 year synchronized

etc. con USDNOK - en mi EA un símbolo SGDJPY fue cosido en el código - ¿por qué descargar USDNOK (USDJPY fue cargado con éxito según los registros), en lugar de USDSGD?

En todo caso, el servidor es FIBOGroup-MT5.

P. S. No he visto estos problemas en las construcciones anteriores.

P. P. S. Por favor, compruebe la optimización del ExpertMACD estándar para los últimos 5 años en todas las garrapatas.

Archivos adjuntos:
20120326.log  33 kb
 
notused:

Algo está mal en la última versión del probador de estrategias. De repente (no "de repente", sino después de la actualización a la compilación 619) EA prácticamente ha dejado de probar (lo mismo que en la aplicación #329165) - la memoria comienza a consumir una cantidad enorme (el modo "Todos los ticks" durante 5 años):

La última columna es "Tamaño de la máquina virtual". Como puedes ver tengo 4 núcleos + 4 agentes locales "remotos" (siempre han funcionado bien).

El sistema empieza a ralentizarse horriblemente (sí, 4GB de RAM + 16GB regalados por PageFile) y la velocidad de optimización tiende al infinito. Como se puede ver, el tiempo de la CPU, prácticamente no se compromete.

No se recomienda ejecutar más agentes que núcleos. Un número excesivo de agentes hace que la velocidad disminuya de forma no lineal y que el consumo de recursos aumente. Especialmente cuando sólo hay 4 Gb de memoria y los agentes se comen un gigabyte o más.

No instale agentes remotos en el mismo ordenador en el que trabaja con el terminal.


Hay errores en el registro:

Debe ser por falta de memoria.

Presiono "stop" - la memoria no se libera de inmediato. En 5 minutos desaparecen los agentes locales, en otros dos minutos se libera la memoria remota:

Sí, la memoria (cachés) se libera después de unos 5 minutos. Se guardan a propósito para la siguiente ejecución, de modo que no se pierda tiempo calentando la mayoría de las veces los mismos datos que se utilizaron en la última ejecución.

En la última compilación hemos cambiado la forma de manejar las cachés, lo que las ha aumentado en aras de acelerar las repeticiones.


No está claro por qué un agente tiene más de 100Mb colgando (no creo que haya sido utilizado por Cloud, porque el tiempo de CPU no se utiliza).

Bueno, yo desactivo los agentes locales "remotos". Nada cambia (los retrasos y errores del sistema).

Bueno, creo que el error está en mi Asesor Experto. Por lo tanto, estoy probando un ExpertMACD estándar, EURUSD, h12 de 2007.09.01 a 2012.03.26.

¿Ha recompilado el Asesor Experto después de actualizar a la última versión?

En tu caso el problema está en las ralentizaciones por el constante swapping y la falta de memoria. Consejo: Desactive los agentes remotos innecesarios.

 
Renat:

No se recomienda ejecutar más agentes que núcleos. Un número excesivo de agentes hace que la velocidad disminuya de forma no lineal y que el consumo de recursos aumente. Especialmente cuando sólo hay 4 Gb de memoria y los agentes se están comiendo un gigabyte o más.

Puedes mirar las estadísticas de la Nube - ya sean 4 u 8 agentes - el PR sigue siendo alrededor de 150-190 (excepto uno/dos, que aparentemente caen en el núcleo del navegador)
Renat:

No instale agentes remotos en el mismo ordenador en el que realiza su trabajo principal con el terminal.

Los agentes remotos deshabilitados...
Renat:

¿Has recompilado el EA después de actualizarlo a la última versión?

En tu caso el problema está en las ralentizaciones por el constante swapping y la falta de memoria.

Los expertos han vuelto a recopilar. Incluso el ExpertMACD regular recompilado.
Renat:

Un consejo: desactive los agentes remotos innecesarios.

Lo desactivé, ejecuté ExpertMACD para la optimización y:

GS      2       Core 2  22:35:03        genetic pass (14, 128209952076) tested with error "cannot initialize expert"
JD      2       Core 2  22:35:47        genetic pass (18, 83657327618) tested with error "cannot initialize expert"
HK      2       Core 1  22:35:55        genetic pass (21, 125407780989) tested with error "cannot initialize expert"
PN      2       Core 2  22:36:31        genetic pass (23, 119213797642) tested with error "cannot initialize expert"
DQ      2       Core 2  22:36:31        genetic pass (24, 69556992446) tested with error "cannot initialize expert"
PE      2       Core 3  22:36:35        genetic pass (27, 43810326828) tested with error "cannot initialize expert"
EI      2       Core 3  22:37:15        genetic pass (31, 50607133818) tested with error "cannot initialize expert"
MM      2       Core 3  22:37:15        genetic pass (33, 154340017542) tested with error "cannot initialize expert"
OR      2       Core 3  22:38:10        genetic pass (39, 72154186657) tested with error "cannot initialize expert"
RE      2       Core 3  22:38:53        genetic pass (44, 3365963874) tested with error "cannot initialize expert"
NJ      2       Core 3  22:38:53        genetic pass (45, 69101442583) tested with error "cannot initialize expert"
JO      2       Core 3  22:38:53        genetic pass (46, 13607620667) tested with error "cannot initialize expert"
JS      2       Core 1  22:40:24        genetic pass (53, 86662534982) tested with error "cannot initialize expert"
ID      2       Core 1  22:40:24        genetic pass (54, 101351711755) tested with error "cannot initialize expert"
HG      2       Core 1  22:40:24        genetic pass (55, 121960550013) tested with error "cannot initialize expert"

Y ahora deshabilitado todos los agentes (incluidos los locales) excepto uno:

IR      2       Core 1  22:44:22        genetic pass (1, 59037561933) tested with error "cannot initialize expert"
GE      2       Core 1  22:44:56        genetic pass (3, 122174849602) tested with error "cannot initialize expert"

¿y ahora qué? ¿4 GB no son suficientes para un agente? (aunque el uso de la memoria es de 350 MB, el tamaño de la máquina virtual es de 1,24 GB). ¿Y los que no tienen ni siquiera 4 GB?

¿Por qué no lo compruebas? Consulte el post anterior para ver los pasos de la repetición.

 
notused:
Puedes mirar las estadísticas de la Nube - ya sean 4 u 8 agentes - PR sigue en la región de 150-190 (excepto uno/dos, que aparentemente caen en el núcleo del navegador) Agentes remotos deshabilitados... Expertos recompilados. Incluso el ExpertMACD regular recompilado.

Desactivado, corrió ExpertMACD para la optimización y:

Ahora se han desactivado todos los agentes (incluidos los locales) excepto uno:

¿y ahora qué? ¿4 GB no son suficientes para un agente? (aunque el uso de la memoria es de 350 MB, el tamaño de la máquina virtual es de 1,24 GB).

¿Por qué no lo compruebas después de todo? Los pasos de reproducción están en el post anterior

Bastaba con mirar el registro de EA para ver los errores:

ExpertMACD (EURUSD,H1)  22:50:54        1971.01.05 00:00:00   CExpertBase::InitHigh: error initializing object
ExpertMACD (EURUSD,H1)  22:50:54        1971.01.05 00:00:00   OnInit: error initializing indicators

ExpertMACD (EURUSD,H1)	22:55:07	2012.01.01 00:00:00   CSignalMACD::ValidationSettings: slow period must be greater than fast period
ExpertMACD (EURUSD,H1)	22:55:07	2012.01.01 00:00:00   OnInit: error signal parameters

Elija el período de tiempo y los ajustes correctos. Si se utilizan los límites por defecto, se pueden generar muchas configuraciones erróneas.

 
Renat:

Bastó con mirar el registro de EA para ver los errores:

Elige el periodo de tiempo y los ajustes adecuados. Si utiliza los límites por defecto, puede generar un montón de configuraciones erróneas.

Sí, efectivamente, el problema resultó estar en los parámetros por defecto. Los cambié y todo está probando bien. Volví a mi Asesor Experto - hasta ahora parece estar "volando normalmente".

Así, si antes se perdonaba la disponibilidad de dos agentes por núcleo, ahora definitivamente no.

En el fondo2. Estaba equivocado, lo siento por el tiempo tomado (pero el servicio de atención al cliente - #329165 no lo ha resuelto todavía)

 
stringo:
Lo resolveremos.

Está tardando mucho. Mientras tanto, descubrí lo que está mal.

1) Al refactorizar el código, perdí la asignación explícita del valor de la variable y a veces (de forma bastante aleatoria) recibía resultados aleatorios para el volumen de la posición abierta. Una vez corregido este error, he visto que los resultados no han cambiado: los resultados de las pruebas no coinciden con la optimización. Varios trucos de registro y pandereta nos ayudaron a descubrir que el problema es bastante antiguo:

2) Antes del inicio del Campeonato-2011, informé de que el probador hace tratos los fines de semana. Renat prometió comprobarlo. Pero el problema se mantiene hasta hoy. Por casualidad, elegí el inicio del periodo de pruebas 2007.09.01, que es un fin de semana. Por lo tanto, el optimizador no realiza una operación en este día, pero el probador sí. Para ser más precisos, no llega a OrderSend en el optimizador el fin de semana, pero sí en el probador. ¡¡¡A juzgar por la lógica de mi Asesor Experto, he conseguido averiguar que si el periodo de optimización comienza en fin de semana, ACCOUNT_EQUITY = 0 cuando el temporizador se dispara por primera vez!!! En el probador, ACCOUNT_EQUITY = ACCOUNT_BALANCE (que es lo que fijamos en el depósito inicial). Si el inicio del periodo de optimización cae en un día laborable, el comportamiento del optimizador y del comprobador son idénticos.

Entonces, tienes dos bichos:

1) El optimizador permite abrir un acuerdo en un fin de semana, lo que no debería ser (y no digas que esto es mi error - Voy a corregir mis errores, mientras que el error del probador ha sido colgado por más de medio año);

2) Cuando el temporizador se dispara por primera vez, si el comienzo del período cae en la salida, ACCOUNT_EQUITY = 0, mientras que en el probador ACCOUNT_EQUITY = ACCOUNT_BALANCE. Hay que llevarlo a la misma forma (mejor, por supuesto, a CUENTA_EQUIDAD = CUENTA_BALANCE con corrección del primer error).

En el servicio de atención al cliente en la solicitud #329165 adjuntaré un experto para las pruebas.

1234567
Nuevo comentario