Testeur de stratégie MetaTrader 5 et MQL5 Cloud Network - page 4
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
Vous êtes confus. Ce sera un énorme réseau de travailler avec n'importe quel courtier. Vous pouvez exécuter des tests avec les données de n'importe quel courtier de manière transparente. Appuyez sur Start et le tour est joué : toutes les données de l'environnement de marché (symboles, configurations, graphiques) seront téléchargées et leur synchronisation sera vérifiée automatiquement. Il n'est pas nécessaire d'enregistrer les courtiers dans le réseau, les données de différents courtiers ne se chevaucheront jamais, toute la partie serveur du réseau est un énorme cache de données et dans la plupart des cas, vous n'aurez même pas à retélécharger l'historique.
C'est donc ce que je dis : un courtier a un historique sur l'Eura depuis 1999, le second depuis 2005, le troisième depuis 2010. La seule chose à faire est d'espérer que vous disposerez de plus d'instruments et d'une histoire plus ou moins correcte.
Mais si les courtiers prennent conscience et corrigent l'histoire (j'en doute de plus en plus), tout ira bien.
il s'avère que ce ne sera pas un immense réseau où tous les utilisateurs de MT5 seront réunis. Mais il sera divisé en morceaux par DC. Si l'on tient compte du fait que, de facto, l'historique normal n'est disponible qu'à un seul endroit et pour un nombre limité d'instruments, cela devient un peu triste...
Cher Renat,
Y aura-t-il des superordinateurs sur ce réseau (ce serait très utile) ? J'aimerais avoir des capacités avancées à la hauteur des concurrents mondiaux. Et une autre demande - s'il vous plaît faire, si possible, de sorte que la ressource de calcul du réseau peut être utilisé (si désiré) pour le calcul en temps réel des indicateurs et des conseillers experts, pas seulement pour les tests. Sinon, tout perd son sens - pourquoi avoir une super puissance pour les tests, alors que l'indicateur ou le conseiller expert n'a tout simplement pas le temps d'être calculé au moment de l'exécution (goulot d'étranglement).
En théorie, les agents distants et certainement les agents locaux peuvent être combinés en un pool (bien sûr, si une telle possibilité est prévue dans le terminal et le testeur).
Mais quel est l'intérêt de faire tout cela si MQL lui-même fonctionne en "one thread" et qu'un seul cœur est reconnu lors des tests uniques.
Supposons que les développeurs développent quelque chose de similaire et que le système apprenne à "distribuer" un test unique à différents cœurs ou à les mettre en commun...
On rêve, on attend MT6 :)
C'est de cela que je parle : un courtier a un historique avec Euras depuis 1999, un autre depuis 2005 et un troisième depuis 2010.
Qu'est-ce que la profondeur de l'histoire du courtier a à voir avec cela ?
L'optimisation via le MQL5 Cloud Network est la même que l'optimisation sur votre ordinateur (mais plus rapide).
Si le terminal est connecté à Alpari, l'optimisation s'exécutera sur les données Alpari, même si elle est physiquement réalisée sur des centaines d'autres ordinateurs du réseau. Les données sont synchronisées et tous les tests sont effectués dans les mêmes conditions.
Et la question du nombre d'instruments et de la profondeur/qualité de l'historique des différents courtiers n'est pas dans ce fil.
Qu'est-ce que la profondeur de l'histoire du courtier a à voir avec cela ?
L'optimisation par le biais du MQL5 Cloud Network est identique à l'optimisation sur votre ordinateur (mais plus rapide).
Si le terminal est connecté à Alpari, l'optimisation s'exécutera sur les données Alpari, même si elle est physiquement réalisée sur des centaines d'autres ordinateurs du réseau. Les données sont synchronisées et tous les tests sont réalisés dans les mêmes conditions.
Et la question du nombre d'instruments et de la profondeur/qualité de l'historique des différents courtiers n'est pas dans ce fil.
C'est ainsi que je parle de l'histoire actuelle d'Alpari que nous connaissons tous très bien.
je suis bien conscient que ce n'est pas dans ce fil, mais mon message daté du 2011.02.23 09:46 est correct (surtout la dernière partie).
Qu'est-ce que la profondeur de l'histoire du courtier a à voir avec cela ?
L'optimisation via le MQL5 Cloud Network est la même que l'optimisation sur votre ordinateur (mais plus rapide).
Si le terminal est connecté à Alpari, l'optimisation s'exécutera sur les données Alpari, même si elle est physiquement réalisée sur des centaines d'autres ordinateurs du réseau. Les données sont synchronisées et tous les tests sont effectués dans les mêmes conditions.
Et la question du nombre d'instruments et de la profondeur/qualité de l'historique des différents courtiers n'est pas dans ce fil.
Andrew alors il s'avère que ceux qui participeront au réseau, téléchargeront l'historique (nécessaire pour le testeur) avant de tester. maintenant multipliez cet historique par le nombre de sociétés de courtage + ajoutez qu'il y a beaucoup d'instruments. ajoutez ici la bourse (car elle apparaîtra un jour) faites une correction pour le fait que tout le monde a un historique différent ! !! .... Calculez le trafic s'il vous plaît ... et la quantité d'espace disque nécessaire ...
P.S. "Et la question sur le nombre d'instruments et la profondeur/qualité de l'historique des différents courtiers n'est pas dans ce fil."
- et si ce n'est pas dans celui-ci ? ou si vous ne vous souciez pas de l'histoire que vous testez ? vous avez une histoire sur votre ordinateur, j'en ai une autre ... et les résultats des tests sont combinés ... si je ne suis pas sûr des données qui ont été (sont) testées, alors il n'est pas nécessaire de faire ce putain de test (et de payer de l'argent pour cela ...). parce que la confiance dans les résultats est nulle ...
Andrew alors il s'avère que celui qui participera au réseau, téléchargera l'historique avant de le tester (nécessaire pour le testeur). maintenant multipliez cet historique par le nombre de sociétés de courtage + ajoutez qu'il y a beaucoup d'instruments. ajoutez ici la bourse (car elle apparaîtra à un moment donné) corrigez pour le fait que chacun a un historique différent ! !! .... Calculez le trafic s'il vous plaît ... et la quantité d'espace disque nécessaire ...
Je pense que la plupart des optimisations s'adapteront à 3-4 paires standard et à quelques courtiers populaires.
Et j'ai aimé l' option de mrProF - ce sera probablement le cas.
Z.I. "Et la question du nombre d'instruments et de la profondeur/qualité de l'historique des différents courtiers n'est pas dans ce fil."
- mais qu'en est-il si ce n'est pas dans ce sujet ? ou si vous ne vous souciez pas de l'historique sur lequel vous testez ? vous avez un historique sur votre ordinateur, j'en ai un autre ... et les résultats des tests sont combinés ... si je ne suis pas sûr des données sur lesquelles les tests ont eu lieu (ce qui se passe), alors il n'a pas besoin de ces putains de tests (et de payer de l'argent pour cela ...). parce que la confiance dans les résultats est nulle ...
L'histoire sera SYNCHRONISÉE. Et les tests ne seront effectués que si l'histoire est IDENTIQUE.
Je pense que la plupart des optimisations s'adapteront à 3-4 paires standard et à quelques courtiers populaires.
Et j'ai aimé l' option de mrProF - ce sera probablement le cas.
L'historique sera synchronisé. Et les tests ne seront effectués que si l'histoire est IDENTIQUE.
Non, comme maintenant il sera synchronisé au premier passage.
Sinon, il se peut qu'aucun agent du réseau n'ait d'historique pour un certain symbole chez un certain courtier.
Mais il y a une particularité ici, si l'historique et les paramètres de test sont mis en cache quelque part dans la partie serveur (dans les répartiteurs), cela peut faire gagner beaucoup de temps.
MQL5 Cloud Paramètres réseau pour l'agent MetaTrader 5 :
Pour qu'un agent puisse travailler dans le MQL5 Cloud Network, il suffit d'activer la case "Autoriser l'utilisation publique des agents". L'agent se connectera à un gestionnaire de réseau géographiquement proche (par exemple, toutes les 5 minutes) pour vérifier la disponibilité des tâches à un certain intervalle (estimé par le ping + l'activité). Si des tâches sont disponibles, l'agent les accepte et les traite et commence à en demander activement de nouvelles sans délai. Dès que les tâches sont épuisées, l'agent repasse en mode d'interrogation peu fréquente, ce qui réduit le trafic et la charge de travail.
Pour que l'agent commence à rapporter de l'argent, vous devez activer l'option "Vendre des ressources informatiques" et indiquer votre connexion active à MQL5.community. Les ressources seront fournies gratuitement si cette option n'est pas cochée ou si le login correct n'est pas spécifié. Même si les agents ont été initialement enregistrés sans être liés à un compte, vous pouvez changer cela à tout moment - il suffit d'ajouter un nouveau login et l'agent sera automatiquement réenregistré dans un nouveau compte lors de la prochaine connexion.
Vous pouvez même réenregistrer un agent d'un compte de travail à un autre. Dans ce cas, les montants précédemment gagnés resteront sur l'ancien compte, et les nouvelles tâches seront payées sur le nouveau compte.
Une caractéristique importante du travail en mode MQL5 Cloud Network est que les agents se connectent aux répartiteurs [1-9].mql5.com via le port SSL(443), ce qui leur permet de passer les pare-feu et les serveurs proxy.
Le nouvel agent fonctionnera en mode hybride :
. Vous pouvez créer un calendrier pour la semaine par les heures où l'agent est disponible pour travailler dans le MQL5 Cloud Network. Par exemple, vous pouvez définir 24 heures le week-end et 9 heures (de 22h00 à 07h00) les jours de semaine.
Ce calendrier ne s'applique pas au mode serveur normal des agents - dans ce mode, les agents sont toujours disponibles.
Nous allons également procéder à un réglage sérieux de la façon dont les agents utilisent les ressources :
- En mode repos, ils dépensent une quantité extrêmement faible de ressources (mémoire, threads et priorité).
- les agents utiliseront une gestion flexible de la priorité des threads, de la mémoire et de l'utilisation du CPU lorsqu'ils sont actifs.
L'un des principaux objectifs est de permettre aux agents de travailler sans interférer avec les utilisateurs qui travaillent.build 404, exécuté metatester64.exe - seuls les deux premiers onglets sont là