Accettazione di ordini SL/TP - pagina 4

Nuovo commento
 
Enrique Dangeroux:

https://www.mql5.com/ru/forum/341117 è ancora un problema attuale

L'ultima volta che ho controllato, questo problema è stato risolto sul broker menzionato.

 

Cari sviluppatori, per favore rispondete alla seguente domanda sull'architettura. L'informazione è necessaria per una domanda di combattimento. Nessun reclamo.


Ci sono due limitatori con lo stesso prezzo e lotti diversi. Da cosa dipende il loro ordine nella sequenza di attivazione?

Ho diverse risposte a questa domanda.

  1. Sul lotto.
  2. Sul numero del biglietto.
  3. Dall'ultima modifica del prezzo di apertura.
  4. Dall'ultima modifica di un ordine (per esempio, il livello di take è stato aggiornato in un ordine Limit).

Se ho capito bene, allora dopo aver modificato il prezzo di apertura il limitatore viene opportunamente inserito nella lista-tabella di tutti i limitatori del server, ordinati per prezzo di apertura. Allora la risposta alla domanda si riduce a: è incorporato all'inizio della lista degli ordini con lo stesso prezzo o alla fine?


La stessa domanda non riguarda i limiti ma i gettoni. Da cosa dipende l'ordine di innesco delle prese identiche? È una posizione ID o qualcos'altro?


Lasciate che vi spieghi come questo potrebbe essere utile in combattimento. Per esempio, ho due limitatori (o tee di posizione) allo stesso livello, ma con lotti diversi. Se l'esecuzione del limite (tee) dipende dall'ultima modifica, allora posso aumentare il FillRate semplicemente modificando i limitatori aumentando il lotto.


Probabilmente, solo qualcuno che ha scritto l'implementazione della parte di server MT5 corrispondente conosce la risposta a questa domanda.

 
Andrei Trukhanovich:

lavorare insieme a un broker per trovare il collo di bottiglia

Cos'è, le api contro il miele?).
 
fxsaber:

Ci sono due limitatori con lo stesso prezzo e lotti diversi. Da cosa dipende il loro ordine nella sequenza di attivazione?

Ho diverse risposte a questa domanda.

  1. Sul lotto.
  2. Sul numero del biglietto.
  3. Dall'ultima modifica del prezzo di apertura.
  4. Dall'ultima modifica di un ordine (per esempio, il livello di take è stato aggiornato al limite).

Credo che la variante 4 sia stata usata nella quarta. Cioè, ogni modifica sposta l'ordine alla fine della coda del livello di prezzo corrispondente.

 
secret:
È come le api contro il miele).

in questo particolare momento in questa particolare situazione, è reciprocamente vantaggioso ed è stato fatto. una rara coincidenza.

 

Gli ordini TP in MT5 sono notevoli in quanto possiamo studiare il FillRate (quale parte dell'ordine viene riempita).

L'analisi di decine di migliaia di questi ordini ha dimostrato che il FillRate dipende molto dal simbolo. Se un pacchetto di ordini TP viene attivato simultaneamente, allora il FillRate diminuisce all'aumentare del numero di ordini nel pacchetto.

Sono state rivelate anche altre sfumature specifiche. Ma questo è già stato discusso con il broker.


La ricetta per aumentare il FillRate: combinare tutti gli stessi tick e limitatori in un limite comune di MT5.


Tuttavia, questi dati sono solo un bonus per questo argomento. Il problema indipendente dal broker è che MT5 è in ritardo con i tick e di conseguenza con l'accettazione degli ordini pendenti (compresi i livelli SL/TP).


E dopo un reindirizzamento, MT5 aspetta ogni volta il prossimo tick per controllare se il prezzo soddisfa il livello TP (o limite) o no. Questo può richiedere fino a secondi. E il controllo dovrebbe sempre essere fatto immediatamente dopo il regresso (o il riempimento parziale).

File:
CheckOrders2.mq5  10 kb
 
fxsaber:

OnTick si attiva qualche millisecondo dopo che il tick è stato scritto sul server commerciale.

// Измеряет размер лага между приходом тика на MT5-сервер и MT5-Терминал.
// Запускать на той же машине, на которой установлен MT5-сервер.

#include <WinAPI\WinAPI.mqh>

input int inPeriod = 10;  // EMA-period
input int inAmount = 100; // Количество тиков для анализа

// Локальное время в миллисекундах.
long TimeLocalMsc()
{
  SYSTEMTIME SystemTime;
  
  kernel32::GetLocalTime(SystemTime);

  MqlDateTime time;
  
  time.year = SystemTime.wYear;
  time.mon = SystemTime.wMonth;
  time.day = SystemTime.wDay;
  time.hour = SystemTime.wHour;
  time.min = SystemTime.wMinute;
  time.sec = SystemTime.wSecond;


  return((StructToTime(time) * 1000 + SystemTime.wMilliseconds));
}

double EMA = 0;
int MaxValue = 0;
int MinValue = INT_MAX;
int Amount = 0;

void OnTick()
{
  static const double Alpha = 1.0 / inPeriod; // EMA-коэффициент для расчета среднего значения.

  MqlTick Tick;
  
  const long time = TimeLocalMsc(); // Локальное время в миллисекундах

  if (SymbolInfoTick(_Symbol, Tick))
  {
    const int Value = (int)(time - Tick.time_msc); // На сколько локальное время отличается от тика.
    
    MaxValue = MathMax(Value, MaxValue); // Максимальное значение.
    MinValue = MathMin(Value, MinValue); // Минимальное значение.
    
    EMA += (Value - EMA) * Alpha; // Среднее значение
    
    if (++Amount >= inAmount) // Если посчитали все тики - распечатываем и выходим.
    {
    #define  TOSTRING(A) #A + " = " + (string)(A) + "\n"      
      Print(TOSTRING(Amount), TOSTRING(MinValue) + TOSTRING(MaxValue) + TOSTRING(EMA) +
            TOSTRING(TerminalInfoInteger(TERMINAL_PING_LAST)));
      
      ExpertRemove();
    }
  }
}


Risultato.

Amount = 100
MinValue = 1
MaxValue = 8
EMA = 4.344007436833947
TerminalInfoInteger(TERMINAL_PING_LAST) = 42


Sono state elaborate 100 zecche. Il ritardo di arrivo tra il server e il terminale di spunta varia da uno a otto millisecondi. La media è di poco più di quattro millisecondi. Questo è uguale al ritardo di attivazione dell'ordine TP, che è dove questo ramo è iniziato.


Il ritardo stesso è all'interno del server MT5. Il canale Server->Terminal non c'entra niente.


Grande richiesta agli sviluppatori di eliminare questo ritardo. Ora con zero ping abbiamo un ritardo costante di tick in entrata non solo al terminale, ma anche al server. In particolare, l'ordine accetta.


ZS Per coloro che spogliano i broker di cucina attraverso l'arbitraggio, questo ritardo incorporato è come il mana dal cielo. Cioè i broker incorrono in un sostanziale rischio aggiuntivo.

 
Su quale server hai controllato?

Su quale strumento e quale gateway/datafide hai usato per formare i dati iniziali?

Se l'orario è stato generato da un fornitore di quote sul suo lato remoto (ad esempio, gateway di scambio) e non dal server MT5 stesso, allora potrebbe esserci un divario.

Quali processi in background potreste dimenticare, come gli stress test con decine e centinaia di migliaia di operazioni in parallelo?
 

Renat Fatkhullin:
На каком сервере проверяли?

Controllato su molti server. Compreso MQ-Demo.

Forum sul trading, sistemi di trading automatico e test di strategie di trading

Accettazione di ordini SL/TP

fxsaber, 2020.11.25 00:47

Risultato dell'esecuzione su MQ-Demo.

Total Orders (from 2020.09.01 00:00:00) = 58493, calculated = 439
Calculation time = 00:00:11.328, Performance = 38.0 orders/sec.

ServerName: MetaQuotes-Demo

Last Tick 2020.09.30 19:07:32.917 1.80181 1.80205
Accepted Tick 2020.09.30 19:07:32.716 1.80178 1.80202
Accepted Length = 357 ms.
Order 726444166 ORDER_TYPE_BUY GBPAUD 2020.09.30 19:07:33.073 1.80206 ORDER_REASON_TP ORDER_STATE_FILLED 2020.09.30 19:07:33.082, Position created 2020.09.30 17:21:17.933, StopLevel = 0

Orders (2) before 726444166 with PositionID = 725926764:
------------------------
Checked Orders = 0
------------------------


Lo script sostiene di aver trovato un ordine TP e un tick che è stato l'innesco della sua creazione (evidenziato in colore nel testo). Sembrerebbe che se il prezzo ha raggiunto il livello TP di una posizione aperta sul server di trading (specialmente sulla demo), l'ordine TP corrispondente dovrebbe essere creato (non necessariamente eseguito) immediatamente. Tuttavia, in questa situazione non è successo immediatamente, ma dopo 357 millisecondi!


Su quale strumento e quale gateway/datafide si sono formati i dati iniziali?

Ho controllato gli strumenti forex, RannForex-Server, AMTS-gateway. Altre configurazioni devono essere chiarite.

Se il tempo è stato formato dal fornitore di quotazioni sul suo lato remoto (per esempio, il gateway di scambio), e non il server MT5 stesso, allora il divario può essere.

Credo che il server MT5 si stesse formando su una macchina con zero ping. Ma richiede un chiarimento per una garanzia del 100%. Tuttavia, quanto sopra ha mostrato che anche sul tuo server il problema.

 
fxsaber:

Indagando sull'esecuzione degli ordini TP, ho notato che alcuni ordini TP sono stati creati con un ritardo significativo rispetto ai tick che li hanno accettati.

Il debriefing ha mostrato che questa situazione si ripete non solo su diversi broker, ma anche nella situazione in cui il trading viene fatto sul terminale, che è sulla stessa macchina del Trading Server. Cioè con un ping molto basso e un solo conto di trading per il Trading Server.

Vi incoraggio a condividere i risultati dei vostri conti. Aiutate a migliorare la MT5!

Avete "dimenticato" un dettaglio molto piccolo - avete controllato 58.000 ordini e avete trovato solo un caso di overshoot a 300 ms. E avreste dovuto concentrarvi chiaramente su questo (1 su 58 000) durante questi controlli.

Proprio come in quelli precedenti con assegni da un milione di dollari dove si cercava anche un singolo outlier e si faceva finta che fosse un comportamento normale.


Abbiamo controllato i log del server e abbiamo potuto vedere che la nostra virtualizzazione con il server MetaQuotes-Demo era fisicamente malata in quei secondi (al 2020.09.30 19:07 per 4 secondi), perché c'erano circa 15 mln di conti e circa 2 mln di posizioni aperte, e nel frattempo qualcosa stava succedendo sui server virtuali e sull'hypervisor vicini.

In ogni caso, indagheremo ulteriormente, anche se ci sono sempre singoli picchi in qualsiasi sistema.

12345678
Nuovo commento
Motivazione: