Erreurs, bugs, questions - page 2904
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
Il n'y a pas d'erreur dans le comportement du terminal. Vous devez comprendre que pour travailler avec 1000 symboles ou plus, vous avez besoin d'un matériel puissant et de beaucoup de mémoire. Il est également recommandé de limiter fortement le nombre de barres sur le graphique (dans les paramètres du terminal).
Au moins un i7 ou un i9 de neuvième ou mieux dixième génération. Mémoire d'au moins 32 Go.
"... n'a laissé que la demande de devis..." - Si vous pensez vraiment que demander des cotations est une opération très simple, abandonnez le trading et ne vous approchez jamais de l'ordinateur.
Peut-être qu'il n'y a pas d'erreur, je ne dis pas que c'est le cas, j'ai juste signalé ce comportement comme un bug possible, ce fil de discussion semble être réservé à cela, ou ai-je tort ?
D'après ce que vous dites, mon matériel est plus qu'adéquat. La consommation de mémoire est d'ailleurs relativement faible pour cette opération, environ 3,5 Go. Tout est OK avec la mémoire, et en général tout fonctionne de manière stable.
Maintenant, j'ai intentionnellement réduit le nombre de barres dans les paramètres de 1mln à 1k. Cela n'a pas fait de différence. Je pense qu'il aura plus d'effet si j'ouvre quelques centaines d'onglets dans le terminal.
La question n'est pas de savoir combien de temps CPU est consommé dans le processus d'énumération, la question est qu'une fois toutes les requêtes terminées, la charge ne diminue pas.
Si nous supposons que pour chaque caractère demandé, un fil distinct est laissé en mémoire (non détruit) pour une utilisation ultérieure, alors tout s'explique et il n'y a plus de questions.
Et ai-je prétendu que la demande de devis est une opération simple ? Ce n'est pas du tout ce que j'ai écrit. Sur la façon dont j'ai simplifié le scénario à un scénario primitif afin que d'autres facteurs n'aient pas d'impact et que je laisse "demande de devis seulement".
Si vous pensez vraiment que le trading nécessite de comprendre que la demande de devis est une opération délicate, ce n'est pas du tout le cas.
Quant au conseil d'abandonner le commerce et de rester loin de l'ordinateur, trop tard. Vous avez 25 ans de retard pour le premier point et 10 ans de retard pour le second.
Si les développeurs le jugent nécessaire, ils tiendront compte de ces informations. S'ils ne le font pas, ils ne le font pas.
Salutations, Alexander.
Peut-être qu'il n'y a pas d'erreur, je ne le prétends pas, j'ai signalé ce comportement comme un bug possible, ce fil de discussion semble être conçu pour cela, ou ai-je tort ?
D'après ce que vous dites, j'ai plus qu'assez de matériel. La consommation de mémoire est d'ailleurs relativement faible pour cette opération, environ 3,5 Go. Tout est OK avec la mémoire, et en général tout fonctionne de manière stable.
Maintenant, j'ai intentionnellement réduit le nombre de barres dans les paramètres de 1mln à 1k. Cela n'a pas fait de différence. Je pense qu'il aura plus d'effet si j'ouvre quelques centaines d'onglets dans le terminal.
La question n'est pas de savoir combien de temps CPU est consommé dans le processus d'énumération, la question est qu'une fois toutes les requêtes terminées, la charge ne diminue pas.
Si nous supposons que pour chaque caractère demandé, un fil distinct est laissé en mémoire (non détruit) pour une utilisation ultérieure, alors tout s'explique et il n'y a plus de questions.
Et ai-je prétendu que la demande de devis est une opération simple ? Ce n'est pas du tout ce que j'ai écrit. Sur la façon dont j'ai simplifié le scénario à un scénario primitif afin que d'autres facteurs n'aient pas d'impact et que je laisse "demande de devis seulement".
Si vous pensez vraiment que le trading nécessite de comprendre que la demande de devis est une opération délicate, ce n'est pas du tout le cas.
Quant au conseil d'arrêter le commerce et de rester loin de l'ordinateur, trop tard. Vous avez 25 ans de retard pour le premier point et 10 ans de retard pour le second.
Si les développeurs le jugent nécessaire, ils tiendront compte de ces informations. S'ils ne le font pas, ils ne le font pas.
Salutations, Alexander.
Avez-vous redémarré votre terminal après avoir diminué le nombre de barres ?
Avez-vous redémarré le terminal après avoir réduit le nombre de barres ?
Avez-vous redémarré le terminal après avoir réduit le nombre de barres ?
Bien sûr.
J'ai fait une expérience.
J'ai ouvert environ 100 fenêtres dans le terminal (il n'en ouvre pas plus, il y a une limite).
La charge du processeur a légèrement augmenté à 8-10% et la taille de la mémoire utilisée a augmenté, ce qui est logique.
Puis j'ai fermé le terminal, je l' ai rouvert, la charge a augmenté jusqu'à 70-80% et après environ une minute, elle s'est normalisée et est revenue à 8-10%.
(Réglez-le sur 1 million de barres dans les paramètres).
Par conséquent, la situation décrite ci-dessus (avec connexion externe), c'est comme on dit, soit un bug, soit une fonctionnalité.
Seuls les développeurs connaissent la bonne réponse.
S'il s'agit d'un bug, fermez alors le terminal et rouvrez-le après une telle opération. L'opération n'est pas fréquente.
Si c'est une fonctionnalité, alors fermer le terminal après une telle opération et le rouvrir est une sacrée solution. L'opération n'est pas fréquente.
Oui, le terminal est censé maintenir un cache des séries chronologiques récemment demandées.
Mais il n'est pas obligé de le faire éternellement, je crois qu'il y avait un délai de 3 ou 5 minutes.
Veuillez noter qu'à partir de la version 2650 :
Pour économiser du trafic, la plateforme de négociation ne télécharge l'historique des prix des instruments qu'au moment de sa demande effective, par exemple lors de l'ouverture d'un graphique ou de l'exécution d'un test. Toutefois, pour les instruments utilisés activement, cela n'est pas toujours pratique. Si vous activez cette nouvelle option, les graphiques des instruments pour lesquels vous avez des positions ouvertes ou des ordres en attente seront mis à jour en arrière-plan chaque fois que vous lancerez la plateforme. Ainsi, lorsque vous ouvrez les graphiques, vous n'aurez pas à attendre que les données soient rechargées, elles seront immédiatement disponibles pour l'analyse.
Oui, le terminal est censé maintenir un cache des séries chronologiques récemment demandées.
Mais il ne devrait pas faire ça éternellement, je crois qu'il y avait un délai de 3 ou 5 minutes.
La seule question posée jusqu'à présent concerne la connexion externe à partir de python.
Veuillez noter qu'à partir de la version 2650 :
Pour économiser du trafic, la plateforme de négociation ne télécharge l'historique des prix des instruments qu'au moment de sa demande effective, par exemple lors de l'ouverture d'un graphique ou de l'exécution d'un test. Cependant, pour les instruments utilisés activement, cela n'est pas toujours pratique. Si vous activez cette nouvelle option, les graphiques des instruments pour lesquels vous avez des positions ouvertes ou des ordres en attente seront mis à jour en arrière-plan chaque fois que vous lancerez la plateforme. Ainsi, lorsque vous ouvrez un graphique, vous n'aurez pas à attendre que les données soient chargées, car elles seront immédiatement disponibles pour l'analyse.
Sur ce point, il existe un avertissement :"Les graphiques des instruments pour lesquels vous avez des positions ouvertes ou des ordres en attente.
De plus, tous les graphiques ont déjà été téléchargés dans la base de données locale pendant l'exécution du script, le trafic est minime.
Bien que ce ne soit pas tout à fait exact, si nous faisons une analogie avec le serveur SQL auquel nous adressons au moins 1 million de demandes de données, alors, oui, il y aura un pic de charge sur le processeur à ce moment-là, mais la charge sur le processeur sera certainement réduite après la fin de l'opération.
Bien sûr, Metatrader n'est pas un serveur sql, c'est une plateforme différente, mais pour une raison quelconque, il me semble qu'après l'exécution des demandes de cotations à MetaTrader et la fermeture de la connexion à celui-ci, tout devrait revenir à la normale. J'espère que les développeurs de metatrader vont nous expliquer.
Quel est le problème avec le retournement dans le testeur ? Dans le fichier joint, une capture d'écran avec un exemple: une positionouverte de vente, fermée par le rollover à l'achat, puis rouverte à la vente, mais avec un volume nul.
En conséquence, la position n'est pas rouverte, elle disparaît. Il est mis en évidence dans la capture d'écran. J'ai déjà écrit à ce sujet, mais sans photos. C'est quoi ce bogue ? Ça rend impossible de le tester.
Je me demande si les développeurs vont réagir à ce problème. Après tout, le retournement est généré par le testeur et non par mon logiciel.
Qui doit résoudre les problèmes liés à la fixation du dernier prix ? Le courtier ou MQ ?