Testeur de stratégie MetaTrader 5 et MQL5 Cloud Network - page 30
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
J'ai peur qu'avec 24 agents sur 8 cœurs (4 essentiellement + hypertrading), vous dépenserez toute la performance du CPU pour fournir l'infrastructure.
L'exposition d'un nombre excessif d'agents entraîne une chute brutale de leur indice de performance RP, ce qui se traduit par un multiple des honoraires.
Je n'ai pas utilisé le cloud depuis un moment. J'ai décidé de l'utiliser dans la sélection des paramètres. Le travail du nuage a été agréablement surprenant.
Si vous broyez un système de réseau distribué pendant une longue période, vous obtenez un bon résultat.
Dans l'ensemble, il n'y a pas moyen que ça dure une heure et demie.
P. S. J'ai transformé le nuage à la volée. En raison de la perte d'internet, les agents à distance ont abandonné. Ensuite, ils n'ont pas voulu se connecter (état autorisé ; au moins deux générations génétiques ne se sont pas connectées) - apparemment, le testeur a décidé qu'il y avait assez à faire sur le nuage, et a laissé les agents libres se reposer. Déconnecter le nuage. Les agents distants sont connectés. J'ai rallumé les nuages. J'ai fini par être raccroché.
Le réseau doit être un peu finalisé pour éviter de telles situations (par exemple, pour se souvenir du temps de passage maximal et si l'attente du passage dure 2 fois plus longtemps que le temps de passage maximal - pour démarrer le même processus sur le meilleur noyau local (ou distant)).
+ TerminalInfoInteger(TERMINAL_MEMORY_AVAILABLE) doit être affiné.
+ la vitesse de la génétique dépend de la vitesse du cœur le plus faible - si mes cœurs ont un PR - 160-180, et les tâches dans le nuage sont distribuées aux cœurs jusqu'à 100. Par conséquent, à chaque génération, mes cœurs doivent rester inactifs pendant un temps considérable et attendre les réponses du nuage pour générer une nouvelle population. Je pense que je devrais abandonner la limite de 100 RP et donner la priorité aux agents dont le RP est supérieur au RP du noyau local le plus faible (+ou du noyau distant, s'il est connecté). Sinon, l'équilibrage de la charge doit être effectué d'une manière ou d'une autre. Par exemple, si nous supposons que toutes les passes s'exécutent sur le même noyau à la même vitesse (dans la vie, bien sûr, ce n'est pas le cas, mais de nombreux experts avec certaines hypothèses, peut être appelé stable dans le temps de test, indépendamment des paramètres). Si le PR du noyau local est de 150 et le PR du noyau dans le nuage est de 100, alors l'agent local doit se voir attribuer 1,5 fois plus de tâches que l'agent dans le nuage. Par ailleurs, si le RP est plus faible, ne donnez pas aux agents du nuage une tâche à la fois, mais donnez une tâche à un plus grand nombre d'agents. Dans ce cas, le temps d'arrêt serait minime. De manière générale, j'aimerais voir des progrès sur cette question
Au cours des 12 dernières heures, le réseau a raccroché trois fois de plus :(
(Et il y a des agents avec un PR < 100 dans les revues de génétique)
Au fait, quelqu'un a-t-il essayé de partager des agents sur un ssd ? Vu que mon disque commence à craquer sur 8 agents, même sans tâches, je soupçonne que la ressource ssd s'épuise rapidement. Et lorsqu'on teste un EA assez léger, la vitesse de calcul, la vitesse du disque dur commence à s'enrayer. Le nombre de téraoctets injectés dans le cache est une bonne question).
Il y a une telle lettre dans l'alphabet (je veux dire ssd), mais je n'ai pas fait de tests spécifiques : comme le serveur avec un tel dispositif est à l'autre bout de la ville. Mais, IMHO, dans tout système il y a un cache disque, qui lisse les accès fréquents au disque.
J'ai décidé d'optimiser un simple grider (timer 30 sec, nouveau contrôle m1 bar) sur tous les ticks pour deux paires. Mes i5 à 4 cœurs (PR=160-170) et i7 à 8 cœurs (PR=170-180) ont été optimisés pendant environ 90 ( !) heures.
Puis il s'est avéré que les passages i5 sont testés 2 fois plus lents (bien que, comme je l'ai déjà écrit plusieurs fois auparavant, c'était l'inverse - i5 + winxp64 était plus rapide que i7 + win7x64). Au début, j'ai fauché la mémoire - l'i7 en a plus.
Puis j'ai accidentellement jeté un coup d'œil au gestionnaire de tâches et j'ai vu que les agents ont la priorité la plus basse (Low). Et je l'ai sur les deux machines. Et si j'ai réussi à faire passer la priorité à Normal sous win7, winxp64bit ne le permet pas pour une raison quelconque. Pendant une demi-journée avec de nouvelles priorités sur i7, mon temps de test a été réduit (apparemment :)) de plusieurs heures.
De tels "décalages" semblent être observés dans les deux dernières versions (ou peut-être que cela ne concerne que moi).
Et la priorité basse est trop cruelle - si l'équipement est utilisé au moins 12 heures par jour, les agents peuvent bénéficier d'une priorité maximale.
En général, je pensais que la priorité changeait automatiquement en fonction de la charge des ressources, mais il semble qu'elle ne change pas d'elle-même :(