Il mio approccio. Il nucleo è il motore. - pagina 147

 

In generale, il problema è quasi risolto.

  1. Abbiamo bisogno che ogni copia dell'EA crei due risorse proprie - una per scrivere messaggi al motore, l'altra per leggere messaggi dal motore.
  2. Il motore ha bisogno di fare un ciclo attraverso le risorse per vedere quante copie dell'EA sono in esecuzione su coppie diverse.
  3. Il motore creerà una lista dinamica di EA in esecuzione, attraverso la quale l'utente cambierà le connessioni.
  4. Successivamente, il motore registrerà i nomi delle risorse per la messaggistica e per la ricezione dei messaggi dagli EA.

  1. Ogni EA funzionerà normalmente, e scriverà i suoi messaggi al motore nel solito modo. Il motore leggerà questi messaggi solo quando è collegato a quell'EA.
  2. Il motore invierà un comando all'EA sull'evento di connessione, e il motore scriverà un kernel di parametri individuali alla risorsa.
  3. Il motore caricherà questo kernel. In seguito, si passerà attraverso gli elementi della GUI e li ridisegnerà in modo che portino informazioni aggiornate.
  4. Dopo questo, il motore scriverà i suoi messaggi all'EA nella sua risorsa per ricevere messaggi.

Al momento, tutti gli EA accedono al motore attraverso una risorsa comune. L'obiettivo è che ogni consulente abbia una risorsa individuale per comunicare con il motore. E il motore sarebbe in grado di ricollegare le risorse per diverse EA.
 
Sono confuso dal fatto che, diciamo, cinque consulenti trasmetteranno l'intero volume dei pacchetti di lavoro se il motore è in funzione con un sesto. Agli altri cinque dovrebbe essere vietato di trasmettere informazioni di lavoro per il momento. Lasciamo che "ascoltino l'etere".
 
Oleg Papkov:
Sono confuso dal fatto che, diciamo che 5 EAs trasmetteranno l'intera quantità di pacchetti di lavoro se il motore funziona con un sesto. Agli altri cinque dovrebbe essere vietato di trasmettere informazioni di lavoro per il momento. Lascia che "ascoltino l'etere".

Sono d'accordo. Questo ha senso.

Quindi funzioneranno normalmente, ma non scriveranno messaggi alla risorsa. Solo ad una copia del kernel dei parametri. E quando è collegato, scriverà il kernel dei parametri nella risorsa e il motore lo caricherà. Una volta connesso, l'Expert Advisor inizierà a scrivere messaggi per il motore nella risorsa messaggi.

 

La domanda riguarda la connessione.

Il motore espone un piccolo indirizzo stringa a tutti gli EA. Il kernel nell'EA con lo stesso indirizzo di riconoscimento viene richiamato e il funzionamento standard del motore-avvisatore inizia automaticamente. Quando il motore passa a un altro EA, il motore passa il kernel dell'EA con cui stava lavorando allo stato di attesa dell'indirizzo, proprio come gli altri EA in quel momento. A questo punto, tutti gli EA sono disconnessi e il motore è in attesa dell'altro indirizzo dell'EA di cui il motore ha bisogno.

Il kernel del nuovo EA risponde ed entra nello stato di funzionamento standard. La volta successiva il motore continua a inviare il traguardo e lo stato di attesa non viene cambiato. Oltre allo scambio standard, l'Expert Advisor deve analizzare un flusso per controllare se in esso appare la fine della linea di lavoro. All'inizio dei pacchetti di scambio ci deve essere una stringa che indica a chi è indirizzato un pacchetto dal motore. Quel kernel riceve il pacchetto di controllo e inizia a inviare pacchetti del suo stato con la frequenza specificata.

Gli altri aspettano di essere indirizzati attraverso una stringa di identificazione unica per ogni EA. Al momento della commutazione, il motore invia all'attuale EA una stringa di fine vita. L'EA smette di inviare qualsiasi cosa ed entra nello stato di riconoscimento della propria stringa di riconoscimento che è allo stesso tempo l'inizio del lavoro standard di scambio con il motore.

 
Oleg Papkov:

La domanda riguarda la connessione.

Il motore espone un piccolo indirizzo stringa a tutti gli EA. Il kernel nell'EA con lo stesso indirizzo di riconoscimento viene richiamato e il funzionamento standard del motore-avvisatore inizia automaticamente. Quando il motore passa a un altro EA, il motore passa il kernel dell'EA con cui stava lavorando allo stato di attesa dell'indirizzo, proprio come gli altri EA in quel momento. A questo punto, tutti gli EA sono disconnessi e il motore è in attesa dell'altro indirizzo dell'EA di cui il motore ha bisogno.

Il kernel del nuovo EA risponde ed entra nello stato di funzionamento standard. La volta successiva il motore continua a inviare il traguardo e lo stato di attesa non viene cambiato. Oltre allo scambio standard, l'Expert Advisor deve analizzare un flusso per controllare se in esso appare la fine della linea di lavoro. All'inizio dei pacchetti di scambio ci deve essere una stringa che indica a chi è indirizzato un pacchetto dal motore. Quel kernel riceve il pacchetto di controllo e inizia a inviare pacchetti del suo stato con la frequenza specificata.

Gli altri aspettano di essere indirizzati attraverso una stringa di identificazione unica per ogni EA. Al momento della commutazione, il motore invia all'attuale EA una stringa di fine vita. L'EA smette di inviare qualsiasi cosa ed entra nello stato di riconoscimento della propria stringa di riconoscimento che è allo stesso tempo l'inizio del lavoro standard di scambio con il motore.

Le risorse sono un po' più semplici. Non hai bisogno di un indirizzo, solo di un nome di risorsa. Lei ha un modello più complicato. È più semplice.

Il nucleo è semplicemente un array di valori. Ogni Expert Advisor scriverà in esso i valori dei parametri dei suoi elementi della GUI. Quando necessario, gli EA salveranno una copia dei parametri del kernel nella risorsa e il motore la leggerà e ridisegnerà la GUI.

In linea di principio, questo è un compito semplice, ma ci sono molte piccole sfumature. Per esempio, messaggi sull'avvio e l'interruzione della comunicazione con l'EA. Dobbiamo solo pensare al formato.


A proposito, sono riuscito a velocizzare la comunicazione e a diminuire la lentezza. Tuttavia, non ho ancora capito il motivo. Si verifica durante il ridisegno, ma la cosa strana è che il ridisegno stesso non è una frenata. Ma il ridisegno quando si comunica con la risorsa rallenta. La ragione di questo non è ancora chiara.

 

Mettete un qualche tipo di monitoraggio tempo-costo. Così potete vedere dove sta rallentando. E come aggirarlo.

Forse l'ho reso un po' complicato. Non so come sia organizzato all'interno del vostro motore. Stavo solo usando la logica.

 
Oleg Papkov:

Mettete un qualche tipo di monitoraggio tempo-costo. Per vedere dove sta rallentando. E come aggirarlo.

Forse l'ho reso un po' complicato. Non so come sia organizzato all'interno del vostro motore. Stavo solo usando la logica.

La logica ti ha portato più vicino al punto e, in generale, hai capito bene.

Oggi cercherò di andare a fondo delle cause della frenata. Ciò che segue è chiaro: il ridisegno stesso non sta rallentando. Anche la scrittura e la lettura della risorsa non sono lente. Ma insieme otteniamo la lentezza.

 
C'è il monitoraggio, che operazione dura quanto tempo? Devono essere eseguiti in sequenza. Nell'EA, essi, prendendo i dati e inviandoli al motore sono eseguiti ad una frequenza di, diciamo, 30ms. Quando un thread viene inviato al motore, è pronto a ricevere? O cosa fa?
 
Oleg Papkov:
C'è il monitoraggio, quale operazione richiede quanto tempo? Dovrebbero essere eseguiti in sequenza. L'Expert Advisor li esegue, catturando i dati e inviandoli al motore con una frequenza di, diciamo, 30 ms. Quando un thread viene inviato al motore, è pronto a ricevere? O cosa fa?

Controllo tutto ora.

Il motore a 30ms legge la risorsa messaggio dall'EA, e l'EA, alla stessa frequenza, legge la risorsa messaggio dal motore. Sulla stessa frequenza, entrambi si scrivono i loro messaggi (se c'è qualcosa da scrivere). Tutto questo non causa alcun rallentamento. Inoltre, il ridisegno in sé, non causa la frenata.

Tuttavia, il rallentamento appare se c'è una combinazione di ridisegno e scrittura/lettura della risorsa sul lato Engine. La causa di questo non è ancora chiara. Capire cosa fare.

 
Реter Konow:

Controllo tutto ora.

Il motore a 30ms legge la risorsa messaggio dall'EA, e l'EA, alla stessa frequenza, legge la risorsa messaggio dal motore. Sulla stessa frequenza, entrambi si scrivono i loro messaggi (se c'è qualcosa da scrivere). Tutto questo non causa alcun rallentamento. Inoltre, il ridisegno in sé non causa frenate.

Tuttavia, il rallentamento appare se c'è una combinazione di ridisegno e scrittura/lettura della risorsa sul lato Engine. La causa di questo non è ancora chiara. Controllo.

Forse un mismatch: EA e motore, 1 - entrambi si inviano a vicenda, 2 - entrambi ricevono, i loro cicli OnTimer non sono sincronizzati. Aspettando il momento della sincronizzazione casuale per funzionare normalmente. Potrebbe essere questa la ragione?