MetaTrader 5 Strategy Tester e MQL5 Cloud Network - pagina 30
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Ho paura che con 24 agenti su 8 core (4 essenzialmente + hypertrading) spenderete tutte le prestazioni della CPU per fornire infrastrutture.
L'esposizione di un numero eccessivo di agenti fa cadere drasticamente il loro indice di performance PR, con il risultato di un multiplo della tariffa.
Non ho usato la nuvola per un po'. Ho deciso di usarlo nella selezione dei parametri. Il lavoro della nuvola è stato piacevolmente sorprendente.
Se si macina un sistema di rete distribuita per molto tempo, si ottiene un buon risultato.
Tutto sommato, è impossibile che sia un'ora e mezza.
P. S. Ha trasformato la nuvola al volo. A causa della perdita di internet, gli agenti remoti hanno abbandonato. Poi non volevano connettersi (stato autorizzato; almeno due generazioni genetiche non si connettevano) - apparentemente, il tester ha deciso che c'è abbastanza da fare sul cloud, e ha lasciato riposare gli agenti liberi. Disconnesso il cloud. Gli agenti remoti sono collegati. Ha riacceso le nuvole. Finito con una riattaccata.
La rete deve essere un po' finalizzata per evitare tali situazioni (per esempio, per ricordare il tempo massimo di passaggio e se l'attesa del passaggio dura 2 volte di più del tempo massimo di passaggio - per avviare lo stesso processo sul miglior core da locale (o remoto)).
+ TerminalInfoInteger(TERMINAL_MEMORY_AVAILABLE) deve essere perfezionato
+ la velocità della genetica dipende dalla velocità del core più debole - se i miei core hanno PR - 160-180, e i compiti nel cloud sono distribuiti ai core fino a 100. Di conseguenza, ad ogni generazione, i miei core devono rimanere inattivi per una quantità significativa di tempo e aspettare le risposte dal cloud per generare una nuova popolazione. Penso che dovrei abbandonare il limite di 100PR e dare la priorità a quegli agenti il cui PR è maggiore del PR del nucleo locale più debole (+o del nucleo remoto, se connesso). In caso contrario, il bilanciamento del carico deve essere fatto in qualche modo. Per esempio, se assumiamo che tutti i passaggi vengono eseguiti sullo stesso core alla stessa velocità (nella vita, naturalmente, non è così, ma molti esperti con alcuni presupposti, può essere chiamato stabile nel tempo di test, indipendentemente dai parametri). Se il PR del core locale è 150 e il PR del core nel cloud è 100, allora all'agente locale dovrebbero essere dati 1,5 volte più compiti dell'agente nel cloud. Oppure, se il PR è più basso, non date agli agenti nel cloud un compito alla volta, ma date un compito a una gamma più ampia di agenti. In questo caso, il tempo di inattività sarebbe minimo. In generale, vorrei vedere dei progressi su questo tema
Nelle ultime 12 ore, la rete si è bloccata altre tre volte :(
(E ci sono agenti con PR < 100 nelle riviste di genetica)
A proposito, qualcuno ha provato a condividere gli agenti su un ssd? Considerando come il mio disco inizia a scricchiolare su 8 agenti, anche senza compiti, ho il sospetto che la risorsa ssd si stia esaurendo rapidamente. E quando si testa una EA abbastanza leggera, la velocità di calcolo, la velocità del disco rigido comincia a impantanarsi. Quanti terabyte vengono pompati nella cache è una buona domanda)
C'è una tale lettera nell'alfabeto (voglio dire ssd), ma non ho fatto prove specifiche: poiché il server con tale dispositivo è all'altro capo della città. Ma, IMHO, in qualsiasi sistema c'è una cache del disco, che smussa gli accessi frequenti al disco.
Ho deciso di ottimizzare un semplice grider (timer 30 sec, nuovo controllo della barra m1) su tutti i tick per due coppie. I miei 4 core i5 (PR=160-170) e 8 core i7 (PR=170-180) hanno ottimizzato per circa 90 (!) ore.
Poi si è scoperto che i passaggi i5 sono testati 2 volte più lenti (anche se, come ho già scritto diverse volte prima, era viceversa - i5 + winxp64 era più veloce di i7 + win7x64). All'inizio ho falciato la memoria - l'i7 ne ha di più.
Poi ho accidentalmente dato un'occhiata al task manager e ho visto che gli agenti hanno la priorità più bassa (Low). E ce l'ho su entrambe le macchine. E mentre sono riuscito ad aumentare la priorità a Normal su win7, winxp64bit non lo permette per qualche motivo. Durante mezza giornata con le nuove priorità su i7, il mio tempo di test è stato ridotto (apparentemente :)) di diverse ore.
Tali "ritardi" sembrano essere osservati nelle ultime due build (o forse sembra solo a me).
E Priority Low è troppo crudele - se l'attrezzatura almeno 12 ore al giorno può dare la massima priorità agli agenti.
In generale, pensavo che la priorità in qualche modo cambiasse automaticamente a seconda del carico di risorse, ma sembra che non cambi da sola :(