Errori di sincronizzazione del cloud - pagina 2

[Slava]

Che differenza c'è tra 10 minuti e 20 minuti? Nessuna differenza. 10 minuti sono estremamente lunghi per una singola chiamata. Vuoi testare un EA scritto male? Nessun problema. Ma non espandete i vostri problemi sul server pubblico Cloud. Anche altri utenti vogliono usare il server Cloud. Puoi usare agenti locali e remoti senza alcuna restrizione - Sei il benvenuto

[Alain Verleyen]

cowil:

Ciao Stringo,

In primo luogo, grazie per le informazioni.

Tuttavia, sono interessato al ragionamento di MetaQuotes per questo. Se viene utilizzata una grande quantità di dati "Every Tick" (diciamo per esempio, 2003.1.1 -> 2013.1.1) e l'Expert che viene ottimizzato è ragionevolmente complicato, spesso ci vorranno più di 10 minuti per una singola iterazione di ottimizzazione. C'è una ragione specifica per cui MetaQuotes ha scelto un periodo di 10 minuti come timeout? Inoltre, c'è un modo per l'utente cloud di aumentare questo timeout o è stato "cablato" da MetaQuotes?

stringo:
Ciclo infinito rilevato solo sugli agenti cloud. Se una delle chiamate(OnInit, OnDeinit, OnTick, OnTimer ecc.) funziona più di 10 minuti

Non è una singola ottimizzazione, è una chiamata di segnale a una funzione.

[cowil]

angevoyageur:
Non è una singola ottimizzazione, è una chiamata di segnale a una funzione.

Ah - errore mio - in qualche modo avevo in testa che stavamo parlando di una singola iterazione di ottimizzazione, piuttosto che di una singola chiamata a un gestore di eventi (anche se Stringo aveva specificamente menzionato una singola chiamata a un gestore di eventi). Una singola chiamata a un gestore di eventi che dura più di 10 minuti sarebbe davvero ridicola.Le mie umili scuse - devo aver avuto un calo di concentrazione - il tempo di riposare il cervello :)

Mmmmm - quindi ci deve essere qualcosa di strano che accade all'interno del mio Expert che sta causando OnTick() per richiedere occasionalmente più di 10 minuti per completare una chiamata. È ora di iniziare a scavare...

Comunque, grazie ancora per il vostro aiuto ragazzi!

[Slava]

angevoyageur:
Non è una singola ottimizzazione, è una chiamata di segnale a una funzione.

Esattamente. La chiamata singola non può essere più lunga di 10 minuti su quella degli agenti Cloud

[cowil]

Ciao,

Sto ancora scavando ma fatico a trovare qualcosa. Il fatto che il mio Expert ottimizzi senza problemi i miei agenti locali (cioè nessuna delle percentuali di progresso dei miei agenti si ferma o si ferma in qualsiasi momento, cosa che avrei pensato sarebbe avvenuta se ci fosse stata una sorta di ciclo infinito nella mia funzione OnTick() che durava almeno 10 minuti o più) rende davvero difficile la cosa.

Una cosa di cui sono curioso - cosa indica il numero di PR alla fine del messaggio di errore (cioè ".... expert rejected by MQL5 Cloud Network in 600 sec(PR116)". Qualcuno può far luce su questo?

Grazie in anticipo per il vostro aiuto.

[Alain Verleyen]

cowil:

Ciao,

Sto ancora scavando ma fatico a trovare qualcosa. Il fatto che il mio Expert ottimizzi senza problemi i miei agenti locali (cioè nessuna delle percentuali di progresso dei miei agenti si ferma o si ferma in qualsiasi momento, cosa che avrei pensato sarebbe avvenuta se ci fosse stata una sorta di ciclo infinito nella mia funzione OnTick() che durava almeno 10 minuti o più) rende davvero difficile la cosa.

Una cosa di cui sono curioso - cosa indica il numero di PR alla fine del messaggio di errore (cioè ".... expert rejected by MQL5 Cloud Network in 600 sec(PR116)". Qualcuno può far luce su questo?

Grazie in anticipo per il vostro aiuto.

Il PR è una valutazione delle prestazioni di un agente calcolata secondo uno speciale metodo unificato. Più alto è il PR di un agente, più velocemente svolge il suo compito e più alto è il suo prezzo di noleggio per unità di tempo come risultato.

Vedi qui per maggiori informazioni.

[cowil]

angevoyageur:
Vedi qui per maggiori informazioni.

Ah - questo spiega certamente le cose. Grazie per il tuo aiuto!

[cowil]

Ciao,

Bene, dopo aver passato molte ore durante il fine settimana ad esaminare il mio codice, non sono riuscito a trovare da nessuna parte nel codice del mio Expert la possibilità di un loop infinito. E nel processo, sono anche diventato sempre più convinto che se il mio Expert avesse avuto problemi di loop infiniti, avrei dovuto vederlo diventare evidente quando ho usato i miei agenti locali per ottimizzare il mio Expert. Come ho detto sopra, i miei agenti locali non si fermano in nessuna fase durante un'ottimizzazione del mio Expert - tanto meno per un periodo di dieci minuti o più.

Dopo essermi convinto che i problemi non derivavano dal mio Expert, ho iniziato ad esaminare le altre alternative. Le uniche alternative logiche che potevo vedere erano che c'erano problemi con gli agenti stessi (cioè bug) o problemi con le scatole su cui giravano. Sembra che la seconda di queste alternative sia il colpevole.

Da quello che posso capire, le persone stanno eseguendo gli agenti cloud su tutti i tipi di scatole. Presumo anche che questi agenti cloud siano tutti basati su Windows. La ragione per cui menziono questo è che la mia personale esperienza con le versioni consumer di Windows è che sono notoriamente instabili quando vengono sfruttate per un certo periodo di tempo, tendendo a rallentare o addirittura a bloccarsi quando sono sottoposte a serie richieste di elaborazione.

Le ottimizzazioni che ho cercato di eseguire riguardano un Expert ragionevolmente complesso che viene eseguito su 6-7 anni di dati"Every Tick" - cioè che richiede una ragionevole richiesta di elaborazione e di memoria. Sospettavo che gli agenti nella nuvola che stavano assumendo questo compito non fossero sufficientemente specifici - specialmente considerando che sarebbero stati dei box Windows.

Così ho messo la seguente linea di codice nel mio gestore di eventi OnInit():

    // Check optimisation agent stats...
    if (MQL5InfoInteger(MQL5_OPTIMIZATION) && TerminalInfoInteger(TERMINAL_MEMORY_PHYSICAL) < 32000)
        return(INIT_AGENT_NOT_SUITABLE);

La ragione per cui ho usato TERMINAL_MEMORY_PHYSICAL è che le altre opzioni di memoria:TERMINAL_MEMORY_TOTAL e TERMINAL_MEMORY_AVAILABLE non sono molto utili in quanto forniscono solo lo spazio di indirizzamento virtuale totale in modalità utente del processore dell'host (cioè 4GB per un processore a 32 bit o 8TB per un processore a 64 bit). Non riesco a immaginare nessuna macchina a 64 bit là fuori con 8TB di memoria - almeno, non ancora. :) TERMINAL_CPU_CORES era un altro che avevo considerato, ma alla fine ho deciso di provare solo per la memoria, dato che presumo che qualsiasi macchina con una quantità decente di memoria sia decentemente equipaggiata in tutte le altre aree importanti.

E indovinate un po' - niente più problemi! Tutte le mie ottimizzazioni ora funzionano bene :)

[Clock]

cowil:

Ciao,

Bene, dopo aver passato molte ore durante il fine settimana ad esaminare il mio codice, non sono riuscito a trovare da nessuna parte nel codice del mio Expert la possibilità di un loop infinito. E nel processo, sono anche diventato sempre più convinto che se il mio Expert avesse avuto problemi di loop infiniti, avrei dovuto vederlo diventare evidente quando ho usato i miei agenti locali per ottimizzare il mio Expert. Come ho detto sopra, i miei agenti locali non si fermano in nessuna fase durante un'ottimizzazione del mio Expert - tanto meno per un periodo di dieci minuti o più.

Dopo essermi convinto che i problemi non derivavano dal mio Expert, ho iniziato ad esaminare le altre alternative. Le uniche alternative logiche che potevo vedere erano che c'erano problemi con gli agenti stessi (cioè bug) o problemi con le scatole su cui giravano. Sembra che la seconda di queste alternative sia il colpevole.

Da quello che posso capire, le persone stanno eseguendo gli agenti cloud su tutti i tipi di scatole. Presumo anche che questi agenti cloud siano tutti basati su Windows. La ragione per cui menziono questo è che la mia personale esperienza con le versioni consumer di Windows è che sono notoriamente instabili quando vengono sfruttate per un certo periodo di tempo, tendendo a rallentare o addirittura a bloccarsi quando sono sottoposte a serie richieste di elaborazione.

Le ottimizzazioni che ho cercato di eseguire riguardano un Expert ragionevolmente complesso che viene eseguito su 6-7 anni di dati "Every Tick" - cioè che richiede una ragionevole richiesta di elaborazione e di memoria. Sospettavo che gli agenti nella nuvola che stavano assumendo questo compito non fossero sufficientemente specifici - specialmente considerando che sarebbero stati dei box Windows.

Così ho messo la seguente linea di codice nel mio gestore di eventi OnInit():

La ragione per cui ho usato TERMINAL_MEMORY_PHYSICAL è che le altre opzioni di memoria:TERMINAL_MEMORY_TOTAL e TERMINAL_MEMORY_AVAILABLE non sono molto utili in quanto forniscono solo lo spazio di indirizzamento virtuale totale in modalità utente del processore dell'host (cioè 4GB per un processore a 32 bit o 8TB per un processore a 64 bit). Non riesco a immaginare nessuna macchina a 64 bit là fuori con 8TB di memoria - almeno, non ancora. :) TERMINAL_CPU_CORES era un altro che avevo considerato, ma alla fine ho deciso di provare solo per la memoria, dato che presumo che qualsiasi macchina con una quantità decente di memoria sia decentemente equipaggiata in tutte le altre aree importanti.

E indovinate un po' - niente più problemi! Tutte le mie ottimizzazioni ora funzionano bene :)

Questa sembra una grande idea e sono grato per questo suggerimento.

Tuttavia, 3 cose su questo:

1) Come ho detto sopra, ho anche il problema del ciclo "infinito", ma poiché ho capito da questo thread che "ciclo infinito" è solo la migliore ipotesi per "un evento ha richiesto più di dieci minuti", accetto che potrebbe essere il mio codice. Uso degli indicatori piuttosto complessi, e poiché (almeno credo) calcolano tutta la loro storia quando viene creato il loro handle, questo potrebbe (su computer lenti) richiedere più di dieci minuti.

2) Tuttavia! Di solito il mio cloud si blocca dopo 10-15 minuti. Ma ieri sera ha funzionato perfettamente per 8 ore. Nessun singolo crash, anche se non ho cambiato affatto il codice. Strano!

3) E più importante, perché legato al tuo approccio: Quando si rifiuta un agente in base alla sua memoria, l'agente (e per questo l'intera nuvola) non va in crash, l'ho capito. Ma non credo che una macchina più potente proverà di nuovo lo stesso set di parametri, quindi in pratica si perdono i punti dati dell'ottimizzazione, ho ragione? Diresti che questo è il prezzo da pagare?

Sarò curioso di vedere se i miei agenti funzionano ancora una volta che sono tornato dal lavoro...

[Alain Verleyen]

cowil:
...

Quanti agenti sono disponibili quando si rifiutano tutti quelli con meno di 32G di ram?