MetaTrader 5 Strategie-Tester und MQL5 Cloud Netzwerk - Seite 30
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Ich befürchte, dass Sie bei 24 Agenten auf 8 Kernen (im Wesentlichen 4 + Hypertrading) die gesamte CPU-Leistung für die Bereitstellung der Infrastruktur verwenden werden.
Bei einer zu großen Anzahl von Agenten sinkt ihr PR-Leistungsindex drastisch, was zu einem Vielfachen der Gebühr führt.
Ich habe die Cloud schon eine Weile nicht mehr genutzt. Ich habe beschlossen, sie bei der Auswahl der Parameter zu verwenden. Die Arbeit der Wolke war eine angenehme Überraschung.
Wenn man ein verteiltes Netzwerksystem lange Zeit schleift, erhält man ein gutes Ergebnis.
Alles in allem sind es auf keinen Fall anderthalb Stunden.
P. S. Hat die Wolke im Handumdrehen gedreht. Wegen des Ausfalls des Internets fielen die Fernagenten aus. Dann wollten sie sich nicht verbinden (autorisierter Zustand; mindestens zwei genetische Generationen haben sich nicht verbunden) - offenbar hat der Tester beschlossen, dass es in der Cloud genug zu tun gibt und die freien Agenten ruhen lassen. Trennen Sie die Wolke. Die Fernagenten sind verbunden. Ich habe die Wolke wieder eingeschaltet. Am Ende wurde er aufgehalten.
Das Netzwerk muss ein wenig angepasst werden, um solche Situationen zu vermeiden (z.B. um sich die maximale Durchlaufzeit zu merken und - wenn das Warten auf den Durchlauf 2 mal länger dauert als die maximale Durchlaufzeit - den gleichen Prozess auf dem besten Kern von lokal (oder fern) zu starten).
+ TerminalInfoInteger(TERMINAL_MEMORY_AVAILABLE) muss verfeinert werden
+ Die Geschwindigkeit der Genetik hängt von der Geschwindigkeit des schwächsten Kerns ab - wenn meine Kerne PR - 160-180 haben und die Aufgaben in der Cloud auf die Kerne bis zu 100 verteilt werden. Infolgedessen müssen meine Kerne bei jeder Generation für eine beträchtliche Zeit im Leerlauf arbeiten und auf Antworten aus der Cloud warten, um eine neue Population zu erzeugen. Ich denke, ich sollte die 100PR-Grenze fallen lassen und denjenigen Agenten den Vorrang geben, deren PR größer ist als die PR des schwächsten lokalen Kerns (+oder des entfernten Kerns, falls angeschlossen). Ist dies nicht der Fall, muss ein Lastausgleich vorgenommen werden. Zum Beispiel, wenn wir davon ausgehen, dass alle Pässe auf dem gleichen Kern mit der gleichen Geschwindigkeit laufen (im Leben, natürlich nicht so, aber viele Experten mit einigen Annahmen, kann stabil in der Testzeit genannt werden, unabhängig von Parametern). Wenn die PR des lokalen Kerns 150 und die PR des Kerns in der Cloud 100 beträgt, dann sollte der lokale Agent 1,5 Mal mehr Aufgaben erhalten als der Agent in der Cloud. Wenn die PR geringer ist, sollten Sie den Bearbeitern in der Cloud nicht jeweils eine Aufgabe zuweisen, sondern eine Aufgabe an eine größere Anzahl von Bearbeitern vergeben. In diesem Fall wäre die Ausfallzeit minimal. Generell würde ich mir in dieser Frage Fortschritte wünschen
In den letzten 12 Stunden hat sich das Netz drei weitere Male aufgehängt :(
(Und es gibt Agenten mit PR < 100 in Genetik-Zeitschriften)
Übrigens, hat schon mal jemand versucht, Agenten auf einer SSD freizugeben? Wenn man bedenkt, dass mein Laufwerk schon bei 8 Agenten anfängt zu knirschen, auch ohne Aufgaben, habe ich den Verdacht, dass die SSD-Ressourcen schnell zur Neige gehen. Und beim Testen eines relativ leichten EA, der Rechengeschwindigkeit, fängt die Geschwindigkeit der Festplatte an, ins Stocken zu geraten. Wie viele Terabyte in den Cache gepumpt werden, ist eine gute Frage)
Es gibt einen solchen Buchstaben im Alphabet (ich meine ssd), aber ich habe keine konkreten Tests durchgeführt, da der Server mit einem solchen Gerät am anderen Ende der Stadt steht. Aber IMHO gibt es in jedem System einen Festplatten-Cache, der häufige Zugriffe auf die Festplatte glättet.
Ich beschloss, ein einfaches Raster (Timer 30 Sek., neue m1-Balkensteuerung) auf alle Ticks für zwei Paare zu optimieren. Meine 4 Kerne i5 (PR=160-170) und 8 Kerne i7 (PR=170-180) optimierten für etwa 90 (!) Stunden.
Dann stellte sich heraus, dass i5-Passagen 2 mal langsamer getestet werden (obwohl, wie ich schon mehrmals geschrieben habe, es umgekehrt war - i5 + winxp64 war schneller als i7 + win7x64). Zuerst habe ich den Arbeitsspeicher heruntergeschraubt - der i7 hat mehr davon.
Dann habe ich zufällig einen Blick in den Task-Manager geworfen und gesehen, dass die Agenten die niedrigste Priorität (Niedrig) haben. Und ich habe es auf beiden Rechnern. Und während es mir unter Win7 gelungen ist, die Priorität auf Normal zu erhöhen, ist dies unter Winxp64bit aus irgendeinem Grund nicht möglich. Während eines halben Tages mit neuen Prioritäten auf dem i7 hat sich meine Testzeit (scheinbar :)) um mehrere Stunden verkürzt.
Solche "Lags" scheinen in den letzten beiden Builds zu beobachten zu sein (oder vielleicht kommt es nur mir so vor).
Und Priority Low ist zu grausam - wenn Geräte mindestens 12 Stunden pro Tag können maximale Priorität für Agenten geben.
Im Allgemeinen dachte ich, dass sich die Priorität automatisch in Abhängigkeit von der Ressourcenauslastung ändert, aber es scheint, dass sie sich nicht von selbst ändert :(