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
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?
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.
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!
Non è una singola ottimizzazione, è una chiamata di segnale a una funzione.
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.
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.
Vedi qui per maggiori informazioni.
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 :)
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...
...