MetaTrader 5 Strategy Tester e MQL5 Cloud Network - pagina 2
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
Qui è dove diventa più dettagliato. Per quanto ho capito, c'è un solo nucleo per esecuzione, ma si può scegliere quale + è possibile eseguire diversi terminali.
Per l'esecuzione singola (non in modalità ottimizzazione, ma esecuzione singola) potete scegliere uno degli agenti locali o uno di quelli remoti (lavorando in modalità server).
Per una singola esecuzione, non è possibile selezionare un agente dalla rete MQL5 Cloud Network, perché non ha senso pratico o economico.
In parole povere, non ha senso inizializzare un potente sistema distribuito di rete MQL5 con l'innalzamento della cache e la preparazione dei dati per un singolo test. Lo scopo di MQL5 Cloud Network è quello di eseguire calcoli di ottimizzazione di massa.
Per una singola esecuzione (non in modalità di ottimizzazione, solo un singolo passaggio), è possibile selezionare uno degli agenti locali o uno degli agenti remoti (lavorando in modalità server).
Per una singola esecuzione, non è possibile selezionare un agente da MQL5 Cloud Network, perché non ha senso pratico o economico.
In parole povere, non ha senso inizializzare un potente sistema distribuito di rete MQL5 con l'innalzamento della cache e la preparazione dei dati per un singolo test. Lo scopo di MQL5 Cloud Network è quello di eseguire calcoli di ottimizzazione di massa.
Per una singola esecuzione (non in modalità di ottimizzazione, solo un singolo passaggio), è possibile selezionare uno degli agenti locali o uno degli agenti remoti (lavorando in modalità server).
Per una singola esecuzione, non è possibile selezionare un agente da MQL5 Cloud Network, perché non ha senso pratico o economico.
In parole povere, non ha senso inizializzare un potente sistema distribuito di rete MQL5 con l'innalzamento della cache e la preparazione dei dati per un singolo test. Lo scopo di MQL5 Cloud Network è quello di eseguire calcoli di ottimizzazione di massa.
A proposito di quel pensiero - può essere in termini di "miglioramento" per fare tale tipo di "calcolo" preliminare, diciamo, avendo analizzato la velocità di trasferimento (tempo di salita) delle cache come minus e quelli plus da più core e per confrontare ricevuto con tempo di test solo locale per dare qualche "consiglio" - come non ha senso eseguire su quelli remoti. Infatti non è affatto ovvio all'inizio.
Naturalmente, il test manager cercherà di usare più agenti locali, poi agenti remoti e poi agenti distribuiti per ridurre il costo di calcolo.
Inoltre, stiamo introducendo un meccanismo di elaborazione batch, che può ridurre quasi a zero l'impatto dei ritardi di rete quando si lavora con agenti remoti.
Cioè, il terminale distribuirà i compiti in blocchi di 32-64 corse ad ogni agente, il che ridurrà l'impatto dei ritardi della rete dello stesso numero di volte.
Esempio: ho inviato un batch di 32 compiti in 2KB con parametri da calcolare, e ho ricevuto un pacchetto di risposta di 1KB con risultati da un agente 5 minuti dopo. La linea di fondo è un traffico di rete di 3kb con circa 1 secondo di perdita di trasmissione invece di 32 secondi senza packeting.
Grazie per le risposte, ma molte cose non sono ancora chiare.
Для одиночного прогона (не в режиме оптимизации, а именно одиночный проход) можно выбрать одного из локальных агентов или одного из удаленных (работающих в серверном режиме).
Cosa significa: "remoto, in esecuzione in modalità server"? Non capisco - se installo un agente su un secondo computer usando il componente Metatester, è così? E quelli remoti non in modalità server - come li aggiungo?
Per una singola esecuzione, non è possibile selezionare l'agente da MQL5 Cloud Network, perché non ha senso pratico o economico.
Qui abbiamo bisogno di un supercomputer, o meglio di un cluster di supercomputer che lavorino come un unico nucleo - come un unico agente, ed è necessaria una rete - nessuno ha un tale computer a casa. O almeno la capacità di connettersi a una macchina potente (è possibile, per come la vedo io, se installo l'agente su un computer potente, e lo uso da un portatile durante una singola esecuzione). Esattamente per una sola corsa. In realtà, risulta essere il contrario - non c'è alcun senso pratico nell'usare MQL5 Cloud Network per calcoli di ottimizzazione massicci, se anche la singola esecuzione iniziale è difficile. L'enumerazione delle varianti è il secondo caso, ma la corsa singola non è meno importante, e anche più importante per alcune persone.
Quindi ho capito bene, un agente locale/remoto + terminali multipli
Questo non è affatto chiaro come decifrarlo...
Renat:
Esempio: inviato un pacchetto di 32 corse di 2kb con parametri da calcolare e ricevuto 5 minuti dopo un pacchetto di risposta di 1kb con i risultati dall'agente. Il risultato è 3kb di traffico di rete con circa 1 secondo di perdita di trasmissione invece di 32 secondi senza pacchetto.
Renat:
In parole povere, non ha senso inizializzare un potente sistema distribuito MQL5 Network con elevazione della cache e preparazione dei dati per un singolo test. Lo scopo di MQL5 Cloud Network è quello di eseguire calcoli di ottimizzazione di massa.
Sono d'accordo. Tuttavia, è un peccato che non ci sia la possibilità di eseguire più esecuzioni singole (test) simultaneamente, anche con più core su una singola macchina. Più precisamente, in modo sequenziale, naturalmente, ma senza aspettare il completamento delle corse precedenti. Diverse versioni del terminale sono molto costose in memoria. Ma se il tester fosse un programma autonomo, con la possibilità di eseguire più istanze, sarebbe meglio. Idealmente - un tester multitasking. Ora dobbiamo fare una contorsione - scrivere un file di configurazione con liste di parametri e caricarli da un file alimentando l'ottimizzatore con uno pseudo-contatore di variabili. Non è molto conveniente. Per non parlare del fatto che l'insieme completo dei risultati dei test (transazioni, in particolare) in questa variante deve anche essere calcolato, formattato e scaricato in un file nel deinit. Quindi, l'elaborazione di massa dei risultati di ottimizzazione è abbastanza complicata nella versione attuale del tester. Non puoi nemmeno caricare i risultati dei test di ieri da un file (che esiste!) nella pagina dei "risultati di ottimizzazione" per risolverli avendo un tester "one-click" a portata di mano. Potete almeno implementare una tale possibilità?
Un'altra nota dolente: capisco che durante l'ottimizzazione ci vuole un bel po' di tempo per preparare i dati per gli agenti. È possibile caricare gli agenti non con singoli run-task, ma con batch run (8-16-32)? In questo caso (imho) potremmo ottenere un guadagno tangibile nel tempo totale di ottimizzazione. Per quanto ne so, un tale schema è usato con successo in F4 ora. Credo che diversi set di parametri siano eseguiti in parallelo (potrei sbagliarmi). Quindi, mi piacerebbe avere qualcosa del genere su Firth. Altrimenti il mio tester single-core rimane molte volte indietro rispetto a quello four-core (ne ho già scritto una volta).
//Troppo tardi. Nel momento in cui ho scritto, Renat ha già scritto sull'elaborazione in batch in modo affermativo. Grazie. Molto contento, aspetteremo.
Grazie per le risposte, ma molto rimane poco chiaro.
Il che significa: "remoto, in esecuzione in modalità server"? Non capisco - se si installa un agente su un secondo computer usando il componente Metatester - è questo? E per quanto riguarda la modalità remota, non server, come posso aggiungerli?
È qui che abbiamo bisogno di un supercomputer, o meglio di un cluster di supercomputer, che lavorano come un unico nucleo come un unico agente, e una rete - nessuno ne ha una a casa. O almeno la capacità di connettersi a una macchina potente (è possibile, per come la vedo io, se installo l'agente su un computer potente, e lo uso da un portatile durante una singola esecuzione). Esattamente per una sola corsa. In realtà, risulta essere il contrario - non c'è alcun senso pratico nell'utilizzare la rete MQL5 Cloud Network per calcoli di ottimizzazione massicci, se anche la singola esecuzione iniziale è difficile. Provare le varianti è il secondo caso, ma la corsa singola non è meno importante, e anche più importante per alcune persone.
Non è affatto chiaro come decifrare questo...
1. Una singola esecuzione utilizza un solo core, locale (il vostro PC) o un agente remoto (intranet).
2) Alcuni core possono essere disabilitati.
3. potete selezionare un agente specifico (un nucleo specifico) su cui testare.
È teoricamente possibile eseguire diverse "prove singole" allo stesso tempo (ma allora sarebbero necessari più terminali).
PS
Nel tuo caso con il portatile dovresti spegnere i kernel locali e fare il test su un computer potente (che sia in rete locale o che abbia le risorse massime libere per i test).
MetaDriver:
È possibile caricare gli agenti non in base a singole corse-attività, ma a pacchetti di corse (8-16-32)? In questo caso (imho) si può ottenere un guadagno tangibile nel tempo totale di ottimizzazione. Per quanto ne so, un tale schema è usato con successo in F4 ora.
Quello che non capisco è....