Des miracles avec le testeur. - page 3

Nouveau commentaire
 
notused:
Les résultats des passes ne correspondent pas pour l'optimisation et la passe unique (service-desk - #329165 + EA au même endroit)
Essayons de comprendre.
 
notused:
Les résultats de l'optimisation et de la passe unique ne correspondent pas (service-desk - #329165 + EA là aussi)
Construire 619? Ce problème a également commencé à se poser. Mais pas toujours. Parfois, les résultats sont même les mêmes, c'est-à-dire qu'aucune nouvelle optimisation n'a été effectuée, mais les résultats des tests sont en quelque sorte différents. Par exemple, le bénéfice final dans le graphique diffère de celui de la liste. Après un certain temps, tout est rétabli. Je n'avais jamais remarqué ça avant la version 619 .
 
tol64:
Construire 619? Le même problème a commencé à se produire. Mais pas toujours. Parfois, les résultats sont même les mêmes, c'est-à-dire que je n'ai pas effectué de nouvelle optimisation, mais j'obtiens des résultats différents lors des tests pour une raison quelconque. Par exemple, le bénéfice final dans le graphique diffère de celui de la liste. Après un certain temps, tout est rétabli. Je n'ai jamais remarqué cela avant la version 619 .
Le build 607 (je n'ai pas encore fait la mise à jour vers le nouveau FIBO). Peut-être que le problème se situe au niveau de la multidevise et du timer (OnTick() n'est pas utilisé), mais je ne suis pas sûr.
 
notused:
Le build est toujours 607 (je n'ai pas encore mis à jour le nouveau FIBO). Peut-être que le problème est dû à la multidevise et au timer (OnTick() n'est pas utilisé), mais je ne suis pas sûr.
Ensuite, le nom de la branche est choisi avec précision. Des miracles avec le testeur. )))
 

Il y a un problème avec la dernière version du testeur de stratégie. Soudainement (pas tout à fait "soudainement", mais après la mise à jour de la version 619), l'Expert Advisor a pratiquement cessé de tester (comme dans l'application #329165) - la mémoire a commencé à être consommée immensément (le mode "All ticks" pendant 5 ans) :

La dernière colonne est "Taille de la VM". Comme vous pouvez le voir, j'ai 4 cœurs + 4 agents locaux "distants" (qui ont toujours bien fonctionné).

En même temps, le système commence à être très lent (yup, 4GB RAM + 16GB dédiés à PageFile) et la vitesse d'optimisation tend vers l'infini. Comme vous pouvez le voir, le temps CPU, n'est pratiquement pas engagé.

En même temps, il y a des erreurs dans le journal :

Cela est apparemment dû à un manque de mémoire.

J'appuie sur "stop" - la mémoire n'est pas libérée immédiatement. En 5 minutes, les agents locaux ont disparu, en deux minutes supplémentaires, la mémoire des agents distants a été libérée :

Je ne comprends pas pourquoi un agent a toujours plus de 100 Mo d'attente (je ne crois pas qu'il ait pris le nuage - parce que le temps CPU n'est pas utilisé).

Eh bien, je désactive les agents locaux "distants". Rien ne change (retard et erreurs du système).

Eh bien, je pense que l'erreur est dans mon conseiller expert. Je commence donc à tester un ExpertMACD standard, EURUSD, h12 de 2007.09.01 à 2012.03.26.

И... Même image - décalages, utilisation folle de la mémoire (presque les mêmes valeurs que dans la première image) + "cannot initialize expert".

Dans les deux cas, certains passages réussissent néanmoins.

Journal de bord joint.

Des lignes très intéressantes :

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. avec USDNOK - dans mon EA un symbole SGDJPY a été cousu dans le code - pourquoi télécharger USDNOK (USDJPY a été téléchargé avec succès selon les logs), au lieu de USDSGD ?

Le cas échéant, le serveur est un serveur FIBOGroup-MT5.

P. S. Je n'ai pas vu de tels problèmes dans les versions précédentes.

P. P. S. S'il vous plaît, vérifiez l'optimisation de l'ExpertMACD standard pour les 5 dernières années sur tous les ticks.

Dossiers :
20120326.log  33 kb
 
notused:

Il y a un problème avec la dernière version du testeur de stratégie. Soudainement (pas "soudainement", mais après la mise à jour vers le build 619) EA a pratiquement cessé de tester (comme dans l'application #329165) - la mémoire commence à consommer une quantité énorme (le mode "All ticks" pendant 5 ans) :

La dernière colonne est "Taille de la VM". Comme vous pouvez le voir, j'ai 4 cœurs + 4 agents locaux "distants" (qui ont toujours bien fonctionné).

Le système commence à ralentir terriblement (yup, 4GB RAM + 16GB donnés pour PageFile) et la vitesse d'optimisation tend vers l'infini. Comme vous pouvez le voir, le temps CPU, n'est pratiquement pas engagé.

Il n'est pas recommandé d'exécuter plus d'agents qu'il n'y a de cœurs. Un nombre excessif d'agents entraîne une baisse non linéaire de la vitesse et une augmentation de la consommation de ressources. Surtout quand il n'y a que 4 Go de mémoire et que les agents consomment un gigaoctet ou plus.

N'installez pas les agents distants sur le même ordinateur que celui où vous travaillez avec le terminal.


Il y a des erreurs dans le journal :

Cela doit être dû à un manque de mémoire.

J'appuie sur "stop" - la mémoire n'est pas libérée d'un coup. En 5 minutes, les agents locaux ont disparu, en deux minutes supplémentaires, la mémoire distante est libérée :

Oui, la mémoire (caches) est libérée après environ 5 minutes. Elles sont volontairement conservées pour la prochaine exécution, afin de ne pas perdre de temps à réchauffer le plus souvent les mêmes données que celles utilisées lors de la dernière exécution.

Dans la dernière version, nous avons modifié la façon dont nous gérons les caches, ce qui les a augmentés afin d'accélérer les réexécutions.


On ne comprend pas bien pourquoi un agent a plus de 100 Mo qui traînent (je ne pense pas qu'ils aient été utilisés par Cloud, car le temps CPU n'est pas utilisé).

Eh bien, en désactivant les agents locaux "distants". Rien ne change (retard et erreurs du système).

Eh bien, je pense que l'erreur est dans mon conseiller expert. Je teste donc un ExpertMACD standard, EURUSD, h12 de 2007.09.01 à 2012.03.26.

Avez-vous recompilé l'Expert Advisor après la mise à niveau vers la dernière version ?

Dans votre cas, le problème réside dans les ralentissements dus au swapping constant et au manque de mémoire. Conseil : Désactiver les agents distants inutiles.

 
Renat:

Il n'est pas recommandé d'exécuter plus d'agents qu'il n'y a de cœurs. Un nombre excessif d'agents entraîne une baisse non linéaire de la vitesse et une augmentation de la consommation de ressources. Surtout lorsqu'il n'y a que 4 Go de mémoire et que les agents consomment un gigaoctet ou plus.

Vous pouvez regarder les statistiques du Cloud - qu'il y ait 4 ou 8 agents - le PR est toujours autour de 150-190 (sauf un ou deux, qui tombent apparemment sur le noyau du navigateur).
Renat:

N'installez pas d'agents distants sur l'ordinateur où vous effectuez votre travail principal avec le terminal.

Agents distants désactivés...
Renat:

Avez-vous recompilé l'EA après la mise à niveau vers la dernière version ?

Dans votre cas, le problème réside dans les ralentissements dus au swapping constant et au manque de mémoire.

Experts recompilés. Même l'ExpertMACD normal s'est recompilé.
Renat:

Un conseil : désactivez les agents distants inutiles.

Je l'ai désactivé, j'ai lancé ExpertMACD pour l'optimiser et.. :

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"

Et maintenant, j'ai désactivé tous les agents (y compris les agents locaux) sauf un :

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"

et maintenant quoi ? 4GB n'est pas suffisant pour un agent ? (bien que l'utilisation de la mémoire soit de 350 Mo, la taille de la VM = 1,24 Go). Et ceux qui n'ont même pas 4 Go ?

Pourquoi ne vérifiez-vous pas ? Voir le post précédent pour les étapes de relecture.

 
notused:
Vous pouvez regarder les statistiques du Cloud - soit 4 ou 8 agents - PR est toujours dans la région de 150-190 (sauf un / deux, qui tombent apparemment sur le noyau du navigateur) Agents distants désactivés ... Experts recompilés. Même l'ExpertMACD normal s'est recompilé.

Déconnecté, exécuté ExpertMACD pour l'optimisation et :

Maintenant, tous les agents (y compris les agents locaux) sont désactivés, sauf un :

et maintenant quoi ? 4GB n'est pas suffisant pour un agent ? (bien que l'utilisation de la mémoire soit de 350 Mo, la taille de la VM = 1,24 Go).

Pourquoi ne pas le vérifier après tout ? Les étapes de reproduction sont dans le post précédent

Il suffisait de regarder dans le journal d'EA pour voir les erreurs :

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

Choisissez la bonne période et les bons paramètres. Si vous utilisez les limites par défaut, vous pouvez générer un grand nombre de paramètres erronés.

 
Renat:

Il suffisait de regarder le journal de l'EA pour voir les erreurs :

Choisissez la bonne période et les bons paramètres. Si vous utilisez les limites par défaut, vous risquez de générer un grand nombre de paramètres erronés.

Oui, en effet, le problème s'est avéré être dans les paramètres par défaut. Je les ai changés et tout se passe bien. Je suis retourné à mon conseiller expert - jusqu'à présent, il semble "voler normalement".

Donc, si auparavant la disponibilité de deux agents par noyau était pardonnée, maintenant elle ne l'est plus.

Ligne de fond2. Je me suis trompé, désolé pour le temps pris (mais le service-desk - #329165 n'a pas encore trouvé la solution).

 
stringo:
On va trouver une solution.

Ça prend beaucoup de temps. En attendant, j'ai trouvé ce qui ne va pas.

1) En refactorant le code, j'ai perdu l'affectation explicite de la valeur de la variable et j'ai parfois (de manière assez aléatoire) reçu des résultats aléatoires pour le volume de la position ouverte. Après avoir corrigé cette erreur, j'ai vu que les résultats n'ont pas changé - les résultats du test ne coïncident pas avec l'optimisation. Diverses astuces d'abattage et de tambourin nous ont permis de découvrir que le problème est assez ancien :

2) Avant le début du Championnat-2011, j'ai signalé que le testeur fait des affaires le week-end. Renat a promis de le vérifier. Mais le problème demeure à ce jour. Par pur hasard, j'ai choisi le début de la période de test 2007.09.01, qui est un week-end. Ainsi, l'optimiseur n'effectue pas de transaction ce jour-là, mais le testeur le fait. Pour être plus précis, il n'atteint pas OrderSend dans l'optimiseur le week-end, mais il l'atteint dans le testeur. En me basant sur la logique de mon Expert Advisor, j'ai réussi à découvrir que si la période d'optimisation commence le week-end, ACCOUNT_EQUITY = 0 lorsque la minuterie se déclenche pour la première fois ! !! Dans le testeur, ACCOUNT_EQUITY = ACCOUNT_BALANCE (c'est ce que nous avons défini dans le dépôt initial). Si le début de la période d'optimisation tombe un jour ouvrable, les comportements de l'optimiseur et du testeur sont identiques.

Donc, vous avez deux bugs :

1) L'optimiseur vous permet d'ouvrir une transaction un week-end, ce qui ne devrait pas être le cas (et ne dites pas que c'est mon erreur - je corrigerai mes erreurs, alors que le bug du testeur traîne depuis plus de six mois) ;

2) Lorsque la minuterie se déclenche, si le début de la période tombe sur la sortie, ACCOUNT_EQUITY = 0, mais dans le testeur ACCOUNT_EQUITY = ACCOUNT_BALANCE. Nous devons le ramener à la même forme (mieux, bien sûr, à ACCOUNT_EQUITY = ACCOUNT_BALANCE avec correction de la première erreur).

Dans le service-desk à la demande #329165 je vais joindre un expert pour les tests.

1234567
Nouveau commentaire
Raison: