Mon approche. Le noyau est le moteur. - page 147
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
En général, le problème est presque résolu.
Je suis confus par le fait que, disons, 5 EA transmettront la quantité totale de paquets de travail si le moteur fonctionne avec un sixième. Les cinq autres devraient être interdits de transmettre des informations sur le travail pour le moment. Laissez-les simplement "écouter les ondes".
Je suis d'accord. C'est logique.
Ils fonctionneront donc normalement, mais ils n'écriront pas de messages à la ressource. Seulement à une copie du noyau de paramètres. Et lorsqu'il sera connecté, il écrira le noyau du paramètre dans la ressource et le moteur le chargera. Une fois connecté, le conseiller expert commence à écrire des messages pour le moteur dans la ressource de messages.
La question porte sur la connexion.
Le moteur expose une petite adresse de type chaîne à tous les EA. Le noyau de l'EA ayant la même adresse de reconnaissance est rappelé et l'opération standard du moteur-conseil démarre automatiquement. Lorsque le moteur passe à un autre EA, il fait passer le noyau de l'EA avec lequel il travaillait à l'état d'attente d'adresse, tout comme les autres EA à ce moment-là. À ce stade, tous les EA sont déconnectés et le moteur attend l'autre adresse de l'EA dont il a besoin.
Le noyau de la nouvelle EA répond et passe en état de fonctionnement standard. La fois suivante, le moteur continue à envoyer la ligne d'arrivée et l'état d'attente n'est pas modifié. En plus de l'échange standard, l'Expert Advisor doit analyser un flux pour vérifier si la ligne de fin de travail y apparaît. Au début des paquets d'échange, il doit y avoir une chaîne de caractères, indiquant à qui un paquet est adressé par le moteur. Ce noyau reçoit le paquet de contrôle et commence à envoyer des paquets de son état avec la fréquence spécifiée.
Les autres attendent qu'on leur adresse la parole grâce à une chaîne d'identification unique pour chaque EA. Lors de la commutation, le moteur envoie à l'EA actuel une chaîne de fin de vie. L'EA cesse d'envoyer quoi que ce soit et entre dans l'état de reconnaissance de sa propre chaîne de reconnaissance qui est en même temps le début du travail standard d'échange avec le moteur.
La question porte sur la connexion.
Le moteur expose une petite adresse de type chaîne à tous les EA. Le noyau de l'EA ayant la même adresse de reconnaissance est rappelé et l'opération standard du moteur-conseil démarre automatiquement. Lorsque le moteur passe à un autre EA, il fait passer le noyau de l'EA avec lequel il travaillait à l'état d'attente d'adresse, tout comme les autres EA à ce moment-là. À ce stade, tous les EA sont déconnectés et le moteur attend l'autre adresse de l'EA dont il a besoin.
Le noyau de la nouvelle EA répond et passe en état de fonctionnement standard. La fois suivante, le moteur continue à envoyer la ligne d'arrivée et l'état d'attente n'est pas modifié. En plus de l'échange standard, l'Expert Advisor doit analyser un flux pour vérifier si la ligne de fin de travail y figure. Au début des paquets d'échange, il doit y avoir une chaîne de caractères, indiquant à qui un paquet est adressé par le moteur. Ce noyau reçoit le paquet de contrôle et commence à envoyer des paquets de son état avec la fréquence spécifiée.
Les autres attendent qu'on leur adresse la parole grâce à une chaîne d'identification unique pour chaque EA. Lors de la commutation, le moteur envoie à l'EA actuel une chaîne de fin de vie. L'EA cesse d'envoyer quoi que ce soit et entre dans l'état de reconnaissance de sa propre chaîne de reconnaissance qui est en même temps le début du travail standard d'échange avec le moteur.
Les ressources sont un peu plus simples. Vous n'avez pas besoin d'une adresse, juste d'un nom de ressource. Vous avez un modèle plus compliqué. C'est plus simple.
Le noyau est simplement un tableau de valeurs. Chaque conseiller expert y inscrit les valeurs des paramètres de ses éléments GUI. Lorsque cela est nécessaire, les EA enregistrent une copie des paramètres du noyau dans la ressource et le moteur la lit et redessine l'interface graphique.
En principe, il s'agit d'une tâche simple, mais il existe de nombreuses petites nuances. Par exemple, les messages concernant le démarrage et l'arrêt de la communication avec l'EA. Nous devons juste penser au format.
Au fait, j'ai réussi à accélérer la communication et à réduire la lenteur. Cependant, je n'en ai pas encore compris la raison. Il se produit pendant le redécoupage, mais ce qui est étrange, c'est que le redécoupage lui-même ne constitue pas un freinage. Mais le redécoupage lors de la communication via une ressource le fait. La raison de ce phénomène n'est pas encore claire.
Mettez en place une sorte de suivi du coût du temps. Donc vous pouvez voir où ça ralentit. Et comment le contourner.
Peut-être que j'ai rendu ça un peu compliqué. Je ne sais pas comment c'est organisé dans votre moteur. J'utilisais juste la logique.
Mettez en place une sorte de suivi du coût du temps. Pour voir où ça ralentit. Et comment le contourner.
Peut-être que j'ai rendu ça un peu compliqué. Je ne sais pas comment c'est organisé dans votre moteur. J'utilisais juste la logique.
La logique vous a rapproché du but, et en général, vous comprenez correctement.
Aujourd'hui, je vais essayer d'aller au fond des causes du freinage. La suite est claire : le redécoupage lui-même ne ralentit pas. L'écriture et la lecture de la ressource ne sont pas non plus lentes. Mais ensemble, nous obtenons la lenteur.
Il y a un suivi, quelle opération prend combien de temps ? Ils doivent être effectués de manière séquentielle. Le conseiller expert les exécute, en capturant des données et en les envoyant au moteur à une fréquence de, disons, 30 ms. Lorsqu'un fil est envoyé au moteur, est-il prêt à recevoir ? Ou qu'est-ce qu'il fait ?
Je vérifie tout maintenant.
Le moteur lit à 30 ms la ressource message de l'EA, et l'EA, à la même fréquence, lit la ressource message du moteur. Sur la même fréquence, ils s'écrivent mutuellement leurs messages (s'il y a quelque chose à écrire). Tout cela ne provoque aucun ralentissement. De même, le redécoupage lui-même ne provoque pas de freinage.
Cependant, le ralentissement apparaît s'il y a une combinaison de redécoupage et d'écriture/lecture de la ressource du côté du moteur. La cause de ce phénomène n'est pas encore claire. J'ai compris.
Je vérifie tout maintenant.
Le moteur lit à 30 ms la ressource message de l'EA, et l'EA, à la même fréquence, lit la ressource message du moteur. Sur la même fréquence, ils s'écrivent mutuellement leurs messages (s'il y a quelque chose à écrire). Tout cela ne provoque aucun ralentissement. De même, le redécoupage lui-même ne provoque pas de freinage.
Cependant, le ralentissement apparaît s'il y a une combinaison de redécoupage et d'écriture/lecture de la ressource du côté du moteur. La cause de ce phénomène n'est pas encore claire. Je vérifie.
Peut-être un décalage : EA et moteur, 1 - les deux envoient l'un vers l'autre, 2 - les deux reçoivent, leurs cycles OnTimer ne sont pas synchronisés. Attendre le moment de la synchronisation aléatoire pour fonctionner normalement. Cela pourrait-il être la raison ?