MT5 e la velocità in azione - pagina 92

Nuovo commento
 
fxsaber:

Controlla la discrepanza tra TimeLocal e TimeCurrent.

E se TimeLocal() è in ritardo in queste situazioni, la causa è nel sistema operativo?
 
Vasiliy Pushkaryov:
E se TimeLocal() rimane indietro in queste situazioni, la causa è nel sistema operativo?

TimeLocal non è molto indietro. La discrepanza è un broker.

 
Vasiliy Pushkaryov:

Forse qualcuno ha sperimentato, quale può essere la ragione di tali intoppi o freni?

La prima cosa che mi viene in mente è un bug nel codice che fa sì che il calcolo venga eseguito per un tempo molto lungo (ad esempio nel ciclo da 1 a 10 l'intero int viene eseguito a causa del bug)

 
fxsaber:

TimeLocal non è molto indietro. La discrepanza è un broker.

Grazie. Farò un tentativo.
 
Andrei Trukhanovich:

La prima cosa che mi viene in mente è un bug nel codice che innesca un calcolo che richiede molto tempo (per esempio, nel ciclo da 1 a 10 l'intero int viene eseguito a causa del bug).

È scritto nell'aiuto che un EA in loop non può interrompere il lavoro di altri programmi. Tutto si blocca e poi ricomincia a funzionare.

Ho 7 terminali MT4 e tre terminali MT5 che funzionano in parallelo. Forse non c'è abbastanza capacità?



 
Vasiliy Pushkaryov:

Sembra che sia scritto nell'aiuto che un EA in loop non può interrompere altri programmi. E qui tutto si blocca, poi tutto ricomincia a funzionare.

Sì, strano, ho visto solo la scheda degli esperti, non ho visto i log la prima volta.

Ci sono 7 terminali MT4 e tre terminali MT5 che funzionano in parallelo. Forse non c'è abbastanza capacità?

Se è così, allora molto probabilmente tutti i terminali sarebbero rallentati. Inoltre il carico della CPU dovrebbe scalare al 100% in questo caso

 

L'insieme TerminalA - terminali che hanno dati ping(xxx ms) ai punti di accesso.

Il set TerminalB - terminali che non hanno dati di ping(n/a) ai punti di accesso.


I terminali di entrambi i set possono essere collegati allo stesso Access Point e commerciare allo stesso modo - OrderSend viene inviato e le risposte vengono ricevute.


TerminalA carica il processore il meno possibile.


TerminalB:

  • carica la CPU il più possibile.
  • dopo il riavvio rimane TerminalB.
  • Dopo "Rescan network" (manualmente tramite GUI) cambia tipo in TerminalA. Di conseguenza, smette di caricare la CPU.


Se incontrate un carico di CPU inspiegabilmente alto, provate a ripetere la scansione. Questo mi ha aiutato a cambiare tutti i TerminalB in TerminalA.

 

Non so perché, ma il mio broker sembra avere più fatturato, numero di operazioni e numero di conti di trading attivi su MT5 che su MT4.

Purtroppo, ci sono solo informazioni aggregate per piattaforma.

Количество закрытых позиций :129 714
Торговый оборот ($) :$ 5 747 296 372
Активных счетов :498

Ma le prove circostanziali suggeriscono che MT5 è più avanti di MT4. Le ragioni di questo stato di cose sono solo da indovinare.


Quello che so sui clienti:

  • >95% degli scambi (~99% del fatturato) sono auto-trading.
  • Alcuni clienti hanno il terminale MT5 che consuma > 10 giga di memoria (cache storica), MT4 allo stesso volume < 1 giga. Nonostante questo, sono pronti a strapagare per VPS più potenti, ma fanno trading esattamente su MT5, e non su 4.
  • Quasi tutti sono bagarini. Il profitto principale è rappresentato dal trading serale e notturno.
  • L'alta attività (in positivo rispetto ad altri broker) durante il periodo di rollover - enormi spreads.
 
fxsaber TimeCurrent.

Grazie per il suggerimento. Catturato questa situazione. In OnTimer() ha monitorato la discrepanza tra TimeLocal() e TimeCurrent()


Da ieri sera alle 21:58 TimeCurrent() ha iniziato a restituire la stessa ora. Rilasciato oggi alle 00:08. Cioè poco più di due ore ha avuto questa situazione da tutti i personaggi.

 

Non una macchina remota (non VPS) con buone specifiche e un ping al server di trading <4ms ha visto molti casi di lag regolari durante la visualizzazione dei log del terminale (b2958).


Ho preso il primo che ho visto per la dimostrazione qui.

2022.01.18 23:00:09.375  Trades  '': modify order #7133346 sell limit 0.23 USDCHF at 0.91744 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709
2022.01.18 23:00:17.752  Trades  '': accepted modify order #7133346 sell limit 0.23 USDCHF at 0.91741 sl: 0.00000 tp: 0.91709 -> 0.91741, sl: 0.00000 tp: 0.91709
2022.01.18 23:00:17.769  Trades  '': modify #7133346 sell limit 0.23 USDCHF -> price: 0.91741, sl: 0.00000, tp: 0.91709) done in 8393.712 ms


La modifica del limitatore è durata otto secondi. La maggior parte delle modifiche richiede circa questo tempo.

2022.01.18 23:11:00.751 Trades  '': modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712
2022.01.18 23:11:00.761 Trades  '': accepted modify #7133346 sell 0.23 USDCHF sl: 0.00000, tp: 0.91711 -> sl: 0.00000, tp: 0.91712
2022.01.18 23:11:00.763 Trades  '': modify #7133346 sell 0.23 USDCHF -> sl: 0.00000, tp: 0.91712 done in 12.422 ms


Anche per un ping di 4ms è molto, ma ancora niente rispetto agli otto secondi.


Solo i terminali MT5 sono in esecuzione su questa macchina e il carico medio della CPU è ~1%. L'analisi ha dimostrato che durante la frenata il carico raggiunge il 100% quando il mercato e gli ordini di scambio sono molto attivi. Di conseguenza, ci vuole MOLTO tempo per ricevere la risposta dal server commerciale al terminale. In caso di lentezza ho chiesto informazioni al broker. Dal lato del server commerciale tutto è istantaneo e l'ordine raggiunge il server dal terminale sulla prima linea. Cioè l'invio dell'ordine non rallenta, i ritardi avvengono quando si riceve la risposta al terminale.


Dubito che gli sviluppatori saranno in grado di migliorare qualcosa qui. Chi è MOLTO attivo nel trading, per favore condivida le sue osservazioni su questo argomento con i suoi tronchi.

1...85868788899091929394
Nuovo commento
Motivazione: