Testeur de stratégie MetaTrader 5 et MQL5 Cloud Network - page 2
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
C'est ici que ça devient plus détaillé. D'après ce que j'ai compris, il y a un noyau par exécution, mais vous pouvez choisir lequel + il est possible d'exécuter plusieurs terminaux.
Pour une exécution unique (pas en mode optimisation, mais en exécution unique), vous pouvez choisir un des agents locaux ou un des agents distants (travaillant en mode serveur).
Pour une seule exécution, vous ne pouvez pas sélectionner un agent du réseau de nuages MQL5, car cela n'a aucun sens pratique ou économique.
En gros, cela n'a aucun sens d'initialiser un puissant système distribué MQL5 Network avec la levée du cache et la préparation des données pour un seul test. L'objectif du réseau de nuages MQL5 est d'effectuer des calculs d'optimisation massifs.
Pour une seule exécution (pas en mode optimisation, juste une seule passe), vous pouvez sélectionner un des agents locaux ou un des agents distants (travaillant en mode serveur).
Pour une seule exécution, vous ne pouvez pas sélectionner un agent du MQL5 Cloud Network, car cela n'a aucun sens pratique ou économique.
En gros, cela n'a aucun sens d'initialiser un puissant système distribué MQL5 Network avec la levée du cache et la préparation des données pour un seul test. L'objectif du réseau de nuages MQL5 est d'effectuer des calculs d'optimisation massifs.
Pour une seule exécution (pas en mode optimisation, juste une seule passe), vous pouvez sélectionner un des agents locaux ou un des agents distants (travaillant en mode serveur).
Pour une seule exécution, vous ne pouvez pas sélectionner un agent du MQL5 Cloud Network, car cela n'a aucun sens pratique et économique.
En gros, cela n'a aucun sens d'initialiser un puissant système distribué MQL5 Network avec la levée du cache et la préparation des données pour un seul test. L'objectif du réseau de nuages MQL5 est d'effectuer des calculs d'optimisation massifs.
D'ailleurs, cette pensée - peut être en termes d'"amélioration" pour faire ce genre de "calcul" préliminaire, disons, avoir analysé la vitesse de transfert (temps de montée) des caches comme moins et ces plus de plus de cœurs et comparer reçu avec seulement le temps de test local pour donner quelques "conseils" - comme il n'y a aucun sens de la course sur la distance. En fait, ce n'est pas du tout évident au début.
Bien entendu, le gestionnaire de tests essaiera d'utiliser davantage d'agents locaux, puis d'agents distants, et enfin d'agents distribués pour réduire le coût des calculs.
En outre, nous introduisons un mécanisme de traitement par lots, qui peut réduire à presque zéro l'impact des retards de réseau lors du travail avec des agents distants.
En d'autres termes, le terminal distribuera les tâches par blocs de 32 à 64 passages à chaque agent, ce qui réduira l'impact des retards du réseau d'un même nombre de fois.
Exemple : j'ai envoyé un lot de 32 tâches dans 2KB avec des paramètres à calculer, et j'ai reçu un paquet de réponse de 1KB avec les résultats d'un agent 5 minutes plus tard. Le résultat final est un trafic réseau de 3kb avec environ 1 seconde de perte de transmission au lieu de 32 secondes sans mise en paquet.
Merci pour les réponses, mais beaucoup de choses ne sont toujours pas claires.
Для одиночного прогона (не в режиме оптимизации, а именно одиночный проход) можно выбрать одного из локальных агентов или одного из удаленных (работающих в серверном режиме).
Qu'est-ce que cela signifie ? "à distance, fonctionnant en mode serveur" ? Je ne comprends pas : si j'installe un agent sur un deuxième ordinateur en utilisant le composant Metatester, est-ce bien cela ? Qu'en est-il des sites distants qui ne sont pas en mode serveur - comment puis-je les ajouter ?
Pour une seule exécution, vous ne pouvez pas sélectionner l'agent du MQL5 Cloud Network, car cela n'a aucun sens pratique ou économique.
C'est là que nous avons besoin d'un superordinateur, ou plutôt d'un groupe de superordinateurs fonctionnant comme un seul agent, et un réseau est nécessaire - personne n'a un tel ordinateur à la maison. Ou au moins la possibilité de se connecter à une machine puissante (c'est possible, d'après ce que je comprends, si j'installe l'agent sur un ordinateur puissant, et que je l'utilise depuis un ordinateur portable lors d'une seule exécution). Exactement pour une seule course. En fait, il s'avère que c'est le contraire : il n'y a aucun sens pratique à utiliser le MQL5 Cloud Network pour des calculs d'optimisation massifs, si même l'exécution unique initiale est difficile. L'énumération des variantes est le second cas, mais la course unique n'est pas moins importante, et même plus importante pour certaines personnes.
Si je comprends bien, un agent local/à distance + plusieurs terminaux.
Celui-ci n'est pas clair du tout comment le déchiffrer...
Renat:
Exemple : envoi d'un paquet de tâches de 32 exécutions de 2kb avec des paramètres à calculer et réception 5 minutes plus tard d'un paquet de réponses de 1kb avec les résultats de l'agent. Le résultat est 3kb de trafic réseau avec environ 1 seconde de perte de transmission au lieu de 32 secondes sans paquet.
Renat:
En gros, cela n'a aucun sens d'initialiser un puissant système distribué MQL5 Network avec l'élévation du cache et la préparation des données pour un seul test. L'objectif du réseau de nuages MQL5 est d'effectuer des calculs d'optimisation massifs.
Je suis d'accord avec cela. Toutefois, il est dommage qu'il n'y ait pas de possibilité d'exécuter plusieurs cycles uniques (cycles de test) simultanément, même avec plusieurs cœurs sur une seule machine. Plus précisément, de manière séquentielle, bien sûr, mais sans attendre l'achèvement des exécutions précédentes. Plusieurs versions du terminal sont très coûteuses en mémoire. Mais si le testeur était un programme autonome, avec la possibilité d'exécuter plusieurs instances, ce serait mieux. Idéalement - un testeur multitâche. Maintenant, il faut être tordu - écrire un fichier de configuration avec des listes de paramètres et les charger à partir d'un fichier en alimentant l'optimiseur avec un compteur de pseudo-variables. Ce n'est pas très pratique. Sans parler du fait que l'ensemble des résultats des tests (notamment les transactions) dans cette variante doit également être calculé, formaté et versé dans un fichier dans le deinit. Ainsi, le traitement en masse des résultats d'optimisation est assez compliqué dans la version actuelle du testeur. Vous ne pouvez même pas télécharger les résultats des tests d'hier à partir d'un fichier (qui existe bel et bien !) vers la page "résultats d'optimisation" pour les résoudre en ayant un testeur "en un clic" à portée de main. Pouvez-vous au moins mettre en œuvre une telle possibilité ?
Un autre point sensible : je comprends que pendant l'optimisation, il faut beaucoup de temps pour préparer les données pour les agents. Est-il possible de charger les agents non pas avec des exécutions uniques, mais avec des exécutions par lots (8-16-32) ? Dans ce cas (imho), nous pourrions obtenir un gain tangible dans le temps total d'optimisation. Pour autant que je sache, un tel système est utilisé avec succès en F4 maintenant. Je pense que plusieurs jeux de paramètres sont exécutés en parallèle (je peux me tromper). Donc, j'aimerais avoir quelque chose comme ça sur Firth. Sinon, mon testeur à un seul cœur est plusieurs fois à la traîne par rapport à celui à quatre cœurs (j'ai déjà écrit à ce sujet une fois).
//Ouah ! Trop tard. Au moment où j'ai écrit, Renat avait déjà répondu par l'affirmative au sujet du traitement par lots. Merci. Très heureux. Nous attendrons.
Merci pour les réponses, mais beaucoup de choses restent floues.
Ce qui veut dire : "à distance, fonctionnant en mode serveur" ? Je ne comprends pas : si vous installez un agent sur un deuxième ordinateur en utilisant le composant Metatester, est-ce tout ? Et qu'en est-il du mode distant, sans serveur - comment les ajouter ?
C'est là que nous avons besoin d'un superordinateur, ou plutôt d'une grappe de superordinateurs, travaillant comme un seul noyau comme un seul agent, et d'un réseau - personne n'en a chez lui. Ou au moins la possibilité de se connecter à une machine puissante (c'est possible, d'après ce que je comprends, si j'installe l'agent sur un ordinateur puissant, et que je l'utilise depuis un ordinateur portable lors d'une seule exécution). Exactement pour une seule course. En fait, il s'avère que c'est le contraire : il n'y a aucun sens pratique à utiliser le MQL5 Cloud Network pour des calculs d'optimisation massifs, si même l'exécution unique initiale est difficile. L'essai de variantes est le deuxième cas, mais la course unique n'est pas moins importante, et même plus importante pour certaines personnes.
Ce n'est pas du tout clair comment déchiffrer ceci...
1. Une seule exécution n'utilise qu'un seul noyau, local (votre PC) ou agent distant (intranet).
2) Certains cœurs peuvent être désactivés.
3. vous pouvez sélectionner un agent spécifique (un noyau spécifique) sur lequel effectuer le test.
Il est théoriquement possible d'effectuer plusieurs "tests uniques" en même temps (mais il faudrait alors plusieurs terminaux).
PS
Dans le cas de votre ordinateur portable, vous devriez désactiver les noyaux locaux et effectuer le test sur un ordinateur puissant (qui est dans le réseau local ou dont les ressources seront libérées au maximum pour les tests).
MetaDriver:
Est-il possible de charger les agents non pas par des runs-tâches uniques, mais par des paquets de runs (8-16-32) ? Dans ce cas (imho), vous pouvez obtenir un gain tangible dans le temps total d'optimisation. Pour autant que je sache, ce système est utilisé avec succès dans le F4 maintenant.
Ce que je ne comprends pas, c'est.....