Accettazione di ordini SL/TP - pagina 8

[fxsaber]

Andrey Khatimlianskii #:

A proposito, sì, è interessante. Se un piccolo limitatore è sullo stesso livello del TP di una posizione enorme, e quel TP viene reindirizzato perché è grande, il limitatore non avrà nemmeno la possibilità di essere riempito?

Presupposto sbagliato. La coda dei tee scade quando tutti i tee sono stati inviati. Cioè, i limitatori aspettano che tutti i tek siano inviati, non i risultati di questo invio.

Non è la grande quantità di limitatori che può rallentare l'invio di altri limitatori, ma la grande quantità di limitatori al livello di prezzo del limitatore. Per esempio con un lotto minimo.

[Andrey Khatimlianskii]

fxsaber #:

Presupposto sbagliato. La coda dei token scade quando tutti i token sono stati inviati. Cioè, i limitatori aspettano che tutti i tè siano inviati, non i risultati di questo invio.

Non è la grande quantità di limitatori che può rallentare l'invio di altri limitatori, ma la grande quantità di limitatori al livello di prezzo del limitatore. Per esempio con il lotto minimo.

Beh, almeno così. È meglio che eseguire costantemente tutti i TP e i limiti.

Ma dovreste sistemare la coda, ovviamente. Il TP dovrebbe essere un limite regolare.

[fxsaber]

Andrey Khatimlianskii #:

Beh, almeno è così. È meglio che avere tutti i TA e i limiti costantemente applicati.

Ma fissare la coda, ovviamente, è necessario. Il TA dovrebbe essere un normale limitatore.

Ci sono molti più dettagli sull'argomentoqui. Con esempi.

[fxsaber]

fxsaber #:

Ci sono molti più dettagli sull'argomentoqui. Con esempi.

Presumibilmente il tick che attiva l'ordine TP è nato dopo la nascita dell'ordine TP! Cioè, prima è nato l'ordine TP e solo dopo il tick che ha causato la nascita dell'ordine TP. Questo sembra delirante. Quindi diamo un'occhiata dettagliata all'immagine.

La sceneggiatura non ha fatto un errore, è vero! Significa che il database delle zecche è pieno di un enorme ritardo. E il tempo di tick è impostato come tempo di registrazione. Cioè un tempo di tick errato.

Quindi è stato trovato unbug architettonicodi MT5.

La riproduzione di questo bug in MQ-Demo dalla prima volta.

#include <MT4Orders.mqh> // https://www.mql5.com/ru/code/16006

#define  Bid SymbolInfoDouble(_Symbol, SYMBOL_BID)
#define  Ask SymbolInfoDouble(_Symbol, SYMBOL_ASK)

input int inTP = 10;

// Выставляет противоположные позиции с фиксированным тейком.
void OnStart()
{
  OrderSend(_Symbol, OP_BUY, 0.1, Ask, 0, 0, Ask + inTP * _Point);

  OrderSend(_Symbol, OP_SELL, 0.1, Bid, 0, 0, Bid - inTP * _Point);
}

Dopo aver chiuso una posizione, guardiamo l'ora del tick scattato e l'ora del tick che avrebbe dovuto far scattare il controllo.

Vediamo che il tick è scattato 61 ms prima che apparisse il tick che presumibilmente lo ha attivato.

Il bug non si riproduce solo in MQ-Demo: è presente anche nei conti reali. Ma può essere riprodotto immediatamente su MQ-Demo, come mostrato sopra.

Il database dei tick sul server commerciale è distorto, purtroppo.

Stringa di ricerca:Oshibka 042.