FORTI. Problemi di applicazione - pagina 6

 
papaklass:

E cosa ha a che fare il momento della consegna al terminale con il TEMPO di Esecuzione?

La consegna è la consegna e il tempo di esecuzione è il tempo di esecuzione. Una volta che il vostro ordine è stato eseguito, non ci sarà alcuno slittamento, anche se non ha ancora raggiunto il terminale!

Sta dicendo che il terminale non ci informa sul tempo di esecuzione, ma sul tempo di consegna al terminale?

Capisci la differenza, sapientone?

Sei più intelligente di così, scusa....
 
papaklass:

Ho fatto TRE domande nel post che hai commentato e non vedo nessuna risposta. :)

La mente, direttamente scintillante!

 

Sviluppatori, qual è l'opzione giusta? Da quello che dici, sembra che

il client trasmette l'ordine al server molto rapidamente

il server è molto veloce da eseguire

il server è lento a rispondere al client.

o

tuttavia

variante corretta

il cliente invia l'ordine rapidamente

il server non è molto veloce nell'eseguire

il server invia la risposta al client rapidamente

(questi casi sono per la situazione in cui il server MT5 è l'istanza finale dell'ordine di compravendita)


 
papaklass:
Se possibile, eseguire nuovamente l'EA su una nuova build per qualche ora per le statistiche. Il tuo server è molto più potente. Per la purezza dell'esperimento.

Ho 1035 build.

l'esperto è attivo e funzionante

\...

c'è un tronco nel seminterrato.

File:
20141229.log  103 kb
 
papaklass:

Su una nota correlata:

Sembra che ci sia una cosa simile che galleggia sul quattro:

Sì e il tempo di esecuzione è discutibile. Il ping è di 8-9 msec.

MK, pensa su due piattaforme contemporaneamente. Anche se senza ordini asincroni, il quadruplo è significativamente peggiore di quanto potrebbe essere. :)

Riposati nel nuovo anno, irrequieto!

 

Buon pomeriggio, Renat!

Ecco un'altra conferma che i ritardi "vivono" nel server (terminale) MT-5

Trading da casa, via internet (conto reale)

Vedete, il tempo di esecuzione dell'ordine di cancellazione dell'ordine di acquisto è di 11 ms,

e il tempo di esecuzione del secondo ordine, inviato dopo 2 ms, è 3,55 volte maggiore.

Nel mercato morto di oggi questo non si spiega con un "iceberg sottomarino" e le code.

 
Mikalas:

Buon pomeriggio, Renat!

Ecco un'altra prova che i ritardi "vivono" nel server MT-5 (terminale)

Questa non è una prova.

Tu vedi solo le misure dalla tua parte. Non si può supporre che l'intera infrastruttura (software. hardware, canali) sia stabile e abbia ritardi costanti. Soprattutto non si possono fare tali affermazioni quando si misurano i millisecondi.

Anche durante le operazioni di lettura/scrittura con il disco locale, non si può garantire alcuna stabilità della velocità di lettura/scrittura (dove salta anche in decine di millisecondi), in ogni caso stiamo parlando di una rete con un mucchio di nodi intermedi e una propria infrastruttura.


Tanto per essere chiari: quando ci si sposta ai limiti dell'ottimizzazione della velocità (in questo caso decine di millisecondi), è l'infrastruttura, non il software, ad avere il massimo impatto. Non dimenticate che si tratta di una piattaforma al dettaglio, non di un'iniezione diretta nel mercato azionario in un solo passo da una comp vicina su un canale dedicato.

Continueremo a ottimizzare, ma questa volta il nostro impatto sul risultato sarà molto inferiore a quello dell'infrastruttura.


ps: per interesse, misurare i tempi di esecuzione delle transazioni in Quicksilver.

 
In una sveltina, i ritardi possono essere misurati con un cronometro meccanico
 
Edic:
È possibile utilizzare un cronometro meccanico per misurare i ritardi in Quicksilver

Questo è esattamente il mio punto. E qui stiamo parlando di 10-20 ms.

In ogni caso, combatteremo fino alla fine, perché è una priorità per noi. È appena dopo le vacanze.

 
Renat:

Questo è esattamente il mio punto. E qui stiamo parlando di 10-20 ms.

In ogni caso, combatteremo fino alla fine, perché è una priorità per noi. Le vacanze sono appena finite.

In attesa di buoni risultati!
Motivazione: