Cloud-Synchronisationsfehler - Seite 3

Neuer Kommentar
 
Clock:

Das klingt nach einer tollen Idee und ich bin dankbar für diesen Hinweis.

Allerdings, 3 Dinge über das:

1) Wie ich oben erwähnt habe, habe ich auch das Problem der "Endlosschleife", aber da ich aus diesem Thread verstanden habe, dass "Endlosschleife" nur die beste Vermutung für "ein Ereignis dauerte länger als zehn Minuten" ist, akzeptiere ich, dass es an meinem Code liegen könnte. Ich verwende recht komplexe Indikatoren, und da sie (zumindest glaube ich das) ihre gesamte Historie berechnen, wenn ihr Handle erstellt wird, könnte dies (auf langsamen Computern) mehr als zehn Minuten dauern.

2) Wie auch immer! Normalerweise stürzte meine Cloud nach 10-15 Minuten ab. Aber letzte Nacht hat sie 8 Stunden lang perfekt funktioniert. Kein einziger Absturz, obwohl ich den Code überhaupt nicht geändert habe. Seltsam!

3) Und das Wichtigste, weil es mit Ihrem Ansatz zusammenhängt: Wenn man einen Agenten aufgrund seines Speichers ablehnt, stürzt der Agent (und damit die ganze Cloud) nicht ab, das verstehe ich. Aber ich glaube nicht, dass eine leistungsfähigere Maschine den gleichen Parametersatz noch einmal ausprobieren wird, so dass man im Grunde genommen Optimierungsdatenpunkte verliert, oder? Würden Sie sagen, dass dies der Preis ist, den wir zahlen müssen?


Ich bin gespannt, ob meine Agenten noch funktionieren, wenn ich von der Arbeit zurück bin...

Hallo Uhr,

1) Erstens: Wenn Sie nicht gerade Indikatoren für, sagen wir, 10 Jahre mit 1 Mio. Daten verwenden und die Indikatoren unglaublich komplex sind, wäre ich in der heutigen Zeit der Rechenleistung sehr überrascht, dass irgendetwas auf einem NORMALEN System auch nur 5 Minuten dauern würde. Der Grund, warum ich hier "normal" betone, ist, dass ich immer noch vermute, dass eine Reihe von Agenten in der Cloud auf Rechnern laufen, die entweder extrem belastet sind oder einfach einen schweren Fall von Windows (posttraumatischem Stress) haben. Und es braucht nur einen einzigen fehlerhaften Agenten, um Ihre Optimierung zu zerstören....

2) Ich hatte genau dasselbe Problem wie Sie - d. h. nach dem Start einer Optimierung lieferten einige der Cloud-Agenten ohne Probleme Ergebnisse. Dann, nach 5-20 Minuten oder manchmal auch etwas länger, meldete ein Agent den gefürchteten Fehler und BANG - Ende der Optimierung. Es gab aber auch gelegentlich Optimierungen, die ohne Probleme abgeschlossen wurden. Das ist sehr frustrierend, da man keinerlei Zugriff auf die Protokolldateien des Agenten, die Systemdetails, die CPU-Auslastung usw. hat, um zu sehen, was vor sich geht.

3) Das ist ein sehr interessanter Punkt, den Sie ansprechen. Meinem Verständnis nach betrachtet der Optimierer eine bestimmte Parameterkombination nur dann als "verwendet", wenn er die Ergebnisse für diese bestimmte Parameterkombination erhalten hat, obwohl ich damit falsch liegen könnte. Vielleicht kann sich jemand von MetaQuotes zu diesem Punkt äußern?

Wie auch immer, ich hoffe, Sie machen Fortschritte! :)

 
angevoyageur:
Wie viele Agenten stehen zur Verfügung, wenn Sie alle Agenten mit weniger als 32 GB Arbeitsspeicher ablehnen ?

Hallo,

Es scheint eine große Menge an RAM für Consumer-PCs zu sein, aber die Cloud scheint keine Probleme zu haben, Rechner mit diesen Spezifikationen zu finden. Wenn ich eine Optimierung starte, findet der Optimierer problemlos die anfänglichen 64 Agenten und steigert sich dann ziemlich schnell auf 128 (natürlich abhängig von der Konfiguration des Parametersatzes ). Ich habe es zunächst mit 8 GB probiert - die Optimierung lief länger und wurde oft abgeschlossen, aber es kam immer noch regelmäßig vor, dass ein Agent den Fehler produzierte und die Optimierung daraufhin abbrach. Dann habe ich es mit 16 GB versucht - auch hier war es besser, aber nicht fehlerfrei. Ich machte mir nicht die Mühe, es mit 24 GB zu versuchen - ich dachte, ich gehe direkt zu 32 GB und sehe, was passiert :) Und voilà - makellose Optimierungen.

Ich wollte noch viel mehr herumspielen und sehen, ob ich die Anforderungen an die Agentenkonfiguration noch ein wenig verbessern könnte, aber wenn man für das Herumspielen Geld bezahlen muss, ist der Anreiz schnell verschwunden :)

 
cowil:

Hallo,

Es scheint eine große Menge an RAM für Consumer-PCs zu sein, aber die Cloud scheint keine Probleme zu haben, Rechner mit diesen Spezifikationen zu finden. Wenn ich eine Optimierung starte, findet der Optimierer problemlos die anfänglichen 64 Agenten und steigert sich dann ziemlich schnell auf 128 (natürlich abhängig von der Konfiguration des Parametersatzes). Ich habe es zunächst mit 8 GB probiert - die Optimierung lief länger und wurde oft abgeschlossen, aber es kam immer noch regelmäßig vor, dass ein Agent den Fehler produzierte und die Optimierung daraufhin abbrach. Dann habe ich es mit 16 GB versucht - auch hier war es besser, aber nicht fehlerfrei. Ich machte mir nicht die Mühe, es mit 24 GB zu versuchen - ich dachte, ich gehe direkt zu 32 GB und sehe, was passiert :) Und voilà - makellose Optimierungen.

Ich wollte noch viel mehr herumspielen und sehen, ob ich die Anforderungen an die Agentenkonfiguration noch ein wenig verbessern könnte, aber wenn man für das Herumspielen bezahlt wird, ist der Anreiz schnell verschwunden :)

Es wäre interessant, etwas von Metaquotes zurückzubekommen. Wenn ein Rechner mit 16G Ram nicht ausreicht, um einige Optimierungen durchzuführen, gibt es etwas zu untersuchen. Wenn ich es richtig verstanden habe, gibt es keine Probleme, wenn man die Optimierung lokal ausführt, warum braucht man dann so viel Speicher, wenn man die Cloud nutzt?
 
angevoyageur:
Es wäre interessant, eine Rückmeldung von Metaquotes zu erhalten. Wenn ein Rechner mit 16G Ram nicht ausreicht, um eine Optimierung durchzuführen, gibt es etwas zu untersuchen. Wenn ich es richtig verstanden habe, gibt es keine Probleme, wenn man die Optimierung lokal ausführt, warum wird dann bei der Nutzung der Cloud so viel Speicher benötigt?

Ich habe absolut keine Ahnung. Mein lokaler Rechner ist ein Rechner mit 8 GB i7-Prozessor, auf dem MT5 8 lokale Agenten installiert hat (es ist offensichtlich nur ein 4-Kern-Prozessor, aber mit Hyper-Threading sehen Windows und damit MT5 ihn natürlich als 8-Kern-Prozessor). Wenn eine Optimierung durchgeführt wird, scheinen die Agenten jeweils etwa 400 MB Arbeitsspeicher zu verbrauchen, was für die 8 Agenten einen Speicherbedarf von etwa 3,2 GB ergibt. Das sind nicht einmal annähernd 32 GB....

Die andere Sache, über die ich nachgedacht habe und die die eigentliche Ursache für dieses Problem sein könnte, ist die Tatsache, dass ein "schlechter" Cloud-Agent die gesamte Optimierung beendet. Wenn der Cloud-Server Agenten für einen Optimierungsauftrag zuteilt (ohne dass der Speicherbedarf angegeben wird), wird/werden möglicherweise der/die gleiche(n) "schlechte(n)" Agent(en) ausgewählt. Wenn die Speicheranforderungen in OnInit() angegeben werden, werden die "schlechten" Agenten umgangen, weil die Boxen, auf denen sie laufen, die Anforderungen nicht erfüllen, und nur gute Agenten werden ausgewählt. Wenn ich darüber nachdenke, vermute ich, dass dies wahrscheinlich eher der Fall ist.

Und ja, ich habe dieses Problem bei MetaQuotes gemeldet, aber bisher noch keine Antwort erhalten.

 

Wenn OnInit (oder eine andere Funktion) länger als 10 Minuten ausgeführt wird, selbst bei einem langsamen Agenten, wird dies als Endlosschleife betrachtet, die für das MQL5-Cloud-Netzwerk schädlich ist (beachten Sie, dass es keine solche Beschränkung für die lokalen und entfernten Agenten gibt).

Für diese Art von Situationen haben wir den Rückgabecode INIT_AGENT_NOT_SUITABLE für die OnInit-Funktion implementiert. Damit kann ein Cloud-Netzwerk-Benutzer ungeeignete Agenten gleich zu Beginn eines Testlaufs überprüfen und zurückweisen.

Sie können diesen Kommentar als offizielle Antwort auf Ihr Service-Desk-Ticket betrachten. Wir wissen, dass Sie mit den oben genannten Informationen vertraut sind.

Darüber hinaus: In jedem Fall gilt eine Funktion als abnormal, ineffektiv und nicht optimal, wenn ihre Ausführung selbst auf dem langsamsten PC mehr als 10 Minuten dauert.

 
MetaQuotes:

Wenn OnInit (oder eine andere Funktion) länger als 10 Minuten ausgeführt wird, selbst bei einem langsamen Agenten, wird dies als Endlosschleife betrachtet, die für das MQL5-Cloud-Netzwerk schädlich ist (beachten Sie, dass es für lokale und entfernte Agenten keine solche Beschränkung gibt).

Für diese Art von Situationen haben wir den Rückgabecode INIT_AGENT_NOT_SUITABLE für die OnInit-Funktion implementiert. Damit kann ein Cloud-Netzwerk-Benutzer ungeeignete Agenten gleich zu Beginn eines Testlaufs überprüfen und zurückweisen.

Sie können diesen Kommentar als offizielle Antwort auf Ihr Service-Desk-Ticket betrachten. Wir wissen, dass Sie mit den oben genannten Informationen vertraut sind.

Darüber hinaus: In jedem Fall gilt eine Funktion als abnormal, ineffektiv und nicht optimal, wenn ihre Ausführung selbst auf dem langsamsten PC mehr als 10 Minuten dauert.

Hallo MetaQuotes,

zunächst einmal vielen Dank für Ihren Kommentar - ich weiß ihn sehr zu schätzen.

Das Problem, mit dem ich konfrontiert bin (und anscheinend auch andere, wenn Sie sich dieses Posting noch einmal ansehen), besteht darin, dass die Optimierung, wenn sie mit meinen lokalen Agenten durchgeführt wird, gut läuft - d. h. der Status "prozentuale Fertigstellung" für jeden Agenten steigt mit dem Fortschreiten der Optimierung stetig an. Wenn der OnTick()-Ereignishandler in meinem Experten irgendeinen Code enthielte, der mehr als eine Minute (geschweige denn 10 Minuten) zur Fertigstellung bräuchte, würden die Prozentsätze der "prozentualen Fertigstellung" sicherlich zu diesen Zeiten pausieren? Müsste ich nicht Pausen von 10 Minuten (oder mehr) in diesen Statusprozentsätzen sehen, wenn mein Code die Formen von Endlosschleifen enthielte, auf die die Cloud-Agent-Fehler anspielen?

 

Nun, nach vielen Stunden, in denen ich mich mit meinem Experten auseinandergesetzt habe, scheint es, dass ich eine/den Grund für die Probleme mit den OnInit() oder OnTick() "Endlosschleifen"-Fehlern gefunden habe - nämlich den Befehl SymbolInfoInteger(). Ich weiß nicht, ob SymbolInfoDouble() oder SymbolInfoTick() die gleichen Probleme verursachen, da ich bisher noch keine Gelegenheit hatte, weiter zu experimentieren. Wenn jemand dies ausprobieren möchte, führen Sie den folgenden Experten im Optimierer aus, indem Sie Cloud-Agenten verwenden:

/+------------------------------------------------------------------+
//|                                              MultiSymbolTest.mq5 |
//|                                                                  |
//+------------------------------------------------------------------+
input double var1 = 45;
input double var2 = 54;

input bool onInit = true;
input bool onTick = false;


//+------------------------------------------------------------------+
//| expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit() { 

    
    if (onInit) {
    
        string pairsToTrade[] = {"AUDUSD","EURJPY","EURUSD","GBPUSD","AUDJPY","USDJPY","AUDCAD"};
        for (int i=0; i<ArraySize(pairsToTrade); i++) {
            int digits = SymbolInfoInteger(pairsToTrade[i], SYMBOL_DIGITS);
            if (digits == -1)
                return(INIT_FAILED);
        }
    }           

    // Return...
    return(INIT_SUCCEEDED);
}



//+------------------------------------------------------------------+
//| expert start function                                            |
//+------------------------------------------------------------------+
void OnTick() {

    if (onTick) {
    
        string pairsToTrade[] = {"AUDUSD","EURJPY","EURUSD","GBPUSD","AUDJPY","USDJPY","AUDCAD"};
        for (int i=0; i<ArraySize(pairsToTrade); i++) {
            int digits = SymbolInfoInteger(pairsToTrade[i], SYMBOL_DIGITS);
            if (digits == -1)
                return;
        }
    }           

    ExpertRemove();
}    

Wählen Sie aus, ob Sie OnInit() oder OnTick() testen wollen, geben Sie var1 und var2 genügend Start-/Schritt-/Stopp-Werte, um etwa 1000 Kombinationen zu erzeugen (wahrscheinlich reichen auch weniger, aber das ist es, was ich verwendet habe) und starten Sie den Optimierer. In etwa 10 Minuten werden Sie den Fehler "Endlosschleife entdeckt" sehen.

Oh, und der Grund, warum ich das "ExpertRemove()" an das Ende von OnTick() gesetzt habe, war, um zu zeigen, dass es nur eine Iteration von OnTick() braucht, um den Fehler zu erzeugen.

Unnötig zu sagen, dass ich dies auch dem Service Desk gemeldet habe...

 
Oh, und ich vergaß zu erwähnen, dass die Speicherbehebung, die ich oben angegeben habe, das Problem in den meisten Fällen zu beheben scheint, aber nicht in allen. Wie/Warum/Was das funktioniert, weiß ich nicht. Es muss etwas in den Eingeweiden von MT5 kitzeln... :)
 

Ich kann dieses Problem bestätigen:

2013.05.20 14:22:31 MQL5 Cloud Europe 2 genetischer Durchlauf (0, 22) getestet mit Fehler "Endlosschleife in OnInit-Funktion entdeckt, Experte von MQL5 Cloud Network abgelehnt" in 602 sec (PR 140)

 
Ich muss nachdenken...
12345
Neuer Kommentar