Ce que signifie l'entrée dans le journal de bord - page 4

Nouveau commentaire
 
Et je n'ai pas encore vérifié OrderModify :(
Et les ordres en attente:((
 
Ça fait donc un bon bout de temps, quelques jours. Pendant ce temps, plusieurs experts ont réussi à travailler. Voici les logs (le code générant ces logs est ci-dessus). J'attends toujours au moins une réponse des développeurs. Au moins au niveau de "nous reconnaissons le problème, réparons-le".

Journal 1 :
Essayer d'acheter, la tentative 0 a échoué, erreur 6
Essayer d'acheter, tentative 1 a échoué, erreur 129
Essayer d'acheter, tentative 2 a échoué, erreur 129
Essayer d'acheter, tentative 3 a échoué, erreur 129
Essayer d'acheter, tentative 4 a échoué, erreur 129
Erreur d'achat en zigzag : 4050
2.28000000, 0.02700000, 0.00000000
Essayer d'acheter, la tentative 0 a échoué, erreur 6
Essayer d'acheter, tentative 1 réussie

La commande a été ouverte à la 7ème tentative. Plusieurs messages d'erreur ont été reçus en cours de route et n'avaient rien à voir avec la réalité.

Journal de bord 2.
7.9.2005 11:0:15, Signal : vendre7.9.2005 11:0:15 Essayer de vendre, tentative 0.
Ask : 1.24820000, StopLoss : 0.00600000, TakeProfit : 0.00000000
a échoué, erreur 6
7.9.2005 11:0:15 Essayer de vendre, tentative 1.
Ask : 1.24820000, StopLoss : 0.00600000, TakeProfit : 0.00000000
succès de

Au deuxième essai. L'erreur numéro six a fait l'objet de toute une branche, plus d'une centaine de posts. Sur les conseils des développeurs, Rosh et Composter, la fréquence des erreurs est passée de "une fois de temps en temps" à "environ une fois sur cinq". Mais c'est toujours là.

Journal de bord 3.
Tentative de clôture d'une position longue, ticket : 1784257
6.9.2005 12:0:13 Commande avec ce ticket toujours présente, réessayer à nouveau
6.9.2005 12:0:13 Commande avec ce ticket toujours présente, réessayer à nouveau
6.9.2005 12:0:13 Commande avec ce ticket toujours présente, réessayer à nouveau
6.9.2005 12:0:13 Commande avec ce ticket toujours présente, réessayer à nouveau
6.9.2005 12:0:13 Commande avec ce ticket toujours présente, réessayer encore une fois

Cinq échecs, il n'y avait PAS de code d'erreur. Le programme pensait que cette position était fermée. J'attrapais le ticket dans la boucle, si je ne le faisais pas, le problème ne serait pas détecté.

Et ainsi de suite.
 
Faites-le comme ceci
<br / translate="no"> void CloseBuy(string strExpertName)
{
int nTicket = OrderTicket() ;
SaveComment("\r\n\tTentative de clôture d'une position longue, ticket : " + nTicket) ;

int nResult = OrderClose(OrderTicket(), OrderLots(), Bid, nSlip, Aqua) ;

Sleep(10000) ;

si(nResult == -1)
{
int nError = GetLastError() ;
Alert(strExpertName + ", erreur : " + nError) ;
}

}


J'ai dû utiliser une citation pour rendre le texte en gras.
 
Si cela est fait, il est probable que cela masque l'erreur. Et l'objectif est d'aider les développeurs à la trouver, afin que tout fonctionne sans aucune boucle.

L'intérêt de la mise en veille est d'attendre que la condition à l'origine de la panne disparaisse (vous savez, les pings commencent à passer). Parce que, si l'on tient compte du fait que les opérations commerciales "prennent" le contrôle et ne le lâchent pas jusqu'à leur retour, s'il y a une erreur, elle devrait apparaître immédiatement. Si ce n'est pas le cas, il s'agit d'un bogue.

La seule exception possible est ma boucle de vérification d'un ticket d'une position qui vient d'être fermée. Mais même ici, nous pouvons discuter de la manière dont le système devrait idéalement se comporter.

Là encore, le problème n'est pas seulement que les erreurs sont renvoyées, mais aussi que les codes d'erreur sont pris dans le plafond, et parfois il n'y a pas de code du tout - le code de réussite de l'opération est renvoyé.

Si je ne comprends pas quelque chose, veuillez m'expliquer.
 
Explication. Selon les termes d'un conseiller expert, si le cours vendeur actuel dépasse le stop loss d' un ordre de vente en attente, une série d'actions sont exécutées :
1. Un SMS est envoyé pour informer de l'intention de supprimer un tel ordre.
2. Une tentative d'annulation de la commande est effectuée
3. Le résultat de la fonction OrderDelete() est analysé et s'il est négatif (l'ordre n'a pas été supprimé), alors
4. Il envoie un SMS confirmant l'échec.

Hier, nous avons reçu 2 SMS, tout était conforme aux règles mais la commande a été supprimée à la même seconde, selon les journaux.
L'EA essayait donc d'obtenir le résultat de l'opération d' annulation de l'ordre une fraction de seconde plus tôt qu'il ne l'a obtenu. C'est comme dans la blague sur les Chinois qui plantaient des pommes de terre et les déterraient le lendemain. Quand on leur demandait "Est-ce que ça mûrit aussi vite", ils répondaient "Non, mais ça mord" :)
 
Compris, MAIS :
1. J'ai fait toute cette histoire à propos des commandes actuelles. Et s'ils se comportent de la sorte, il faut y remédier.
2) L'idée est que les EA MT devraient être capables de négocier SANS cycle différé. C'est comme ça que ça doit être.
Je vais mettre un délai, mais, comme on dit, "sans plaisir" :)
 
J'ai pensé à moi-même. Si je propose d'utiliser une pause entre l'opération de modification de l'ordre et la vérification des résultats de cette opération, cela signifie que je suppose un fonctionnement asynchrone de l'EA. Cela signifie que nous envoyons une requête au serveur pour essayer de modifier l'ordre et ensuite, sans attendre la réponse, le conseiller expert continue son travail selon l'algorithme. Par défaut, une réponse négative est donnée à l'Expert Advisor jusqu'à ce qu'il reçoive une réponse du serveur. Si la réponse est reçue, la réponse est réelle, mais si elle ne l'est pas, la réponse est virtuelle.

Je n'y crois pas moi-même, les développeurs peuvent-ils m'expliquer à quel point j'ai tort ?
 
Un consensus a été atteint. Mais j'ai fait une pause - juste pour être sûr. Au moins, avant de vérifier la disponibilité du ticket d'une commande qui vient d'être clôturée, on peut accéder à la base de données du serveur, il faut lui laisser le temps de se rafraîchir. Bien que ce soit faux :)

Il est quelque peu embarrassant de constater que sur 37 messages dans ce fil, il n'y en a qu'un seul des développeurs...
 
Il est un peu déconcertant de constater qu'il n'y a qu'un seul message de développeur en 37 dans ce fil...

pourquoi interférer avec une discussion déjà productive
 
pourquoi s'immiscer dans une discussion déjà productive

et voici les produits =)

J'ai fait quelques tests. Il existe un conseiller expert qui ouvre et ferme une position (alternativement achat et vente). Pause minimale entre toutes les transactions - 10 sec.

Temps de test (par Alpari) : 02:00 - 09:30 (soit 7,5 heures)
Tentatives d'envoi de commande: 996
Successful* : 888
Erreurs** : 108

* - Par tentative "réussie", j'entends les éléments suivants : orderSend a renvoyé le numéro du ticket, GetLastError a renvoyé 0, position ouverte sélectionnée avec succès orderselect.
** - Toutes les erreurs #148 "le contexte commercial est occupé" - c'est ce que Slava demandait dans le fil de discussion suivant - "que se passe-t-il si nous désactivons la vérification de isTradeAllowed ? Les erreurs ont commencé à 07:16:46 et s'accumulent toujours)

-----------------------------------------------------------------------------------------------------------------------

Tentatives de fermeture d'ordre: 890
Succès* : 736
Erreurs** : 154

* - par tentative de fermeture "réussie", j'entends ce qui suit : orderclose a retourné true, GetLastError a retourné 0, position fermée sélectionnée avec succès orderselect dans mod_history.
** - 152 erreurs #1 "no error", une #6 et une #138(requotes)


La situation qui a été prise n'a pas eu lieu. C'est-à-dire que toutes les positions fermées étaient effectivement fermées.
1234567
Nouveau commentaire