SL/TP siparişlerinin kabulü - sayfa 4

 
Enrique Dangeroux :

https://www.mql5.com/en/forum/341117 hala gerçek bir sorun

En son kontrol ettiğimde, bu sorun bahsedilen komisyoncuda çözüldü.

 

Sevgili geliştiriciler, lütfen aşağıdaki mimari sorusunu yanıtlayın. Savaş kullanımı için bilgi gereklidir. İddiasız.


Aynı fiyata ve farklı lotlara sahip iki limit vardır. Aktivasyon tetikleme dizisindeki sıralarını ne belirler?

Bu soruya birkaç cevabım var.

  1. Partiden.
  2. Bilet numarasından.
  3. Açılış fiyatının son değişikliğinden.
  4. Emrin son değişikliğinden (örneğin, limit emri için alım seviyesi güncellendi).

Doğru anlarsam, açılış fiyatını değiştirdikten sonra, limit sınırlayıcı, açık fiyata göre sıralanmış olarak tüm sunucu limit limitlerinin liste tablosuna uygun şekilde yerleştirilmiştir. O zaman sorunun cevabı kaynar, aynı fiyatla sipariş listesinin başına mı yoksa sonuna mı gömülüdür?


Aynı soru sınırlarla ilgili değil, alımlarla ilgili. Aynı çekimlerin tetikleme sırasını ne belirler? Konum kimlikleri veya başka bir şey?


Savaşta nasıl yardımcı olabileceğini açıklayayım. Örneğin, aynı seviyede fakat farklı lotlara sahip iki limit emrim (veya pozisyon alımım) var. Limit limitinin (alma) yürütülmesi son değişikliğe bağlıysa, o zaman FillRate, limit emirlerini lotun artan sırasına göre değiştirerek basitçe yükseltilebilir.


Muhtemelen sadece ilgili MT5 sunucu bölümünün uygulamasını yazan kişi bu sorunun cevabını biliyor.

 
Andrei Trukhanovich :

bir darboğaz bulmak için komisyoncu ile birlikte

Arılara karşı bal gibi mi?)
 
fxsaber :

Aynı fiyata ve farklı lotlara sahip iki limit vardır. Aktivasyon tetikleme dizisindeki sıralarını ne belirler?

Bu soruya birkaç cevabım var.

  1. Partiden.
  2. Bilet numarasından.
  3. Açılış fiyatının son değişikliğinden.
  4. Emrin son değişikliğinden (örneğin, limit emri için alım seviyesi güncellendi).

Dördünde seçenek 4 vardı, öyle görünüyor. Yani herhangi bir değişiklik, emri karşılık gelen fiyat seviyesinin kuyruğunun sonuna taşıdı.

 
secret :
Arılar bala karşı mı?)

bu belirli anda bu özel durumda karşılıklı olarak faydalıdır ve yapılmıştır. nadir bir dizi durum.

 

MT5'teki TP siparişleri, FillRate'i (siparişlerin hangi kısmının karşılandığını) inceleyebilmeniz açısından dikkat çekicidir.

Bu tür on binlerce siparişin analizi, FillRate'in sembole çok bağlı olduğunu gösterdi. Aynı anda bir grup TP siparişi tetiklenirse, FillRate partideki bilet numarasında bir artışla düşer.

Diğer özel nüanslar da belirlendi. Ancak bu zaten komisyoncu ile tartışılıyor.


FillRate'i artırmanın tarifi: Tüm aynı alımları ve limitleri tek bir ortak MT5 limitinde birleştirmek.


Ancak, bu veriler bu konuya yalnızca bir bonus. Aracılardan bağımsız bir sorun - MT5, onay işaretleriyle ve buna bağlı olarak bekleyen siparişlerin kabulünde (SL / TP seviyeleri dahil) gecikiyor.


Ve reddetmeden sonra, MT5, fiyatın TP seviyesini (veya limitini) karşılayıp karşılamadığını kontrol etmek için her seferinde bir sonraki onay işaretini bekler. Bu saniyeler sürebilir. Reddetme (veya kısmi doldurma) sonrasında her zaman bir kontrol yapılmalıdır.

Dosyalar:
 
fxsaber :

OnTick, ticaret sunucusunda bir onayın kaydedilmesinden birkaç milisaniye sonra tetiklenir.

 // Измеряет размер лага между приходом тика на 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 ();
    }
  }
}


Sonuç.

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


100 kene işlendi. Sunucu ile Tick Terminali arasındaki varış gecikmesi, bir ila sekiz milisaniye arasında değişir. Ortalama olarak - dört milisaniyeden biraz fazla. Bu, bu şubeyi başlatan TP siparişlerinin tetiklenmesindeki gecikmeye tam olarak eşittir.


Gecikmenin kendisi MT5 sunucusunun içinde bulunur. Sunucu->Terminal kanalının bununla hiçbir ilgisi yoktur.


Bu gecikmeyi düzeltmek için geliştiricilerden büyük bir istek. Artık sıfır pingli borsalarda, yalnızca Terminal'de değil, aynı zamanda Sunucuda da kenelerin gelmesinde sürekli iyi bir gecikme yaşıyoruz. Özellikle, varantların kabulü.


Not: Mutfak komisyoncularını tahkim yoluyla soyanlar için bu, cennetten gelen mana gibi yerleşik bir gecikmedir. Onlar. Brokerler önemli ek riskler.

 
Hangi sunucuyu kontrol ettin?

İlk verileri hangi enstrümanda ve hangi ağ geçidi/veri akışında oluşturdunuz?

Zaman, MT5 sunucusunun kendisi tarafından değil, uzak taraftaki fiyat teklifi sağlayıcısı (örneğin, değişim ağ geçidi) tarafından oluşturulduysa, bir çalışma olabilir.

Onlarca ve yüzbinlerce paralel ticaret operasyonuyla stres testleri gibi arka planda hangi süreçleri unutabilirsiniz?
 

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

Birçok sunucuda kontrol edildi. MQ-Demo dahil.

Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum

SL/TP siparişlerinin kabulü

fxsaber , 2020.11.25 00:47

MQ-Demo'da çalıştırmanın sonucu.

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
------------------------


Komut dosyası, bir TP siparişi ve bunun oluşturulmasını tetikleyen onay işareti (metinde vurgulanmıştır) bulduğunu iddia ediyor. Bir alım satım sunucusunda (özellikle bir demoda) fiyat açık pozisyonun TP seviyesine ulaştıysa, hemen karşılık gelen bir TP emri oluşturulmalıdır (mutlaka yürütülmez). Ancak bu durumda bu anında değil, 357 milisaniye sonra oldu!


İlk verileri hangi enstrümanda ve hangi ağ geçidi/veri akışında oluşturdunuz?

Kontrol edilen forex araçları. RannForex-Sunucusu, AMTS-ağ geçidi. Diğer konfigürasyonların belirtilmesi gerekir.

Zaman, MT5 sunucusunun kendisi tarafından değil de, fiyat teklifi sağlayıcısının uzak tarafında (örneğin, değişim ağ geçidi) oluşturulmuşsa, bir çalışma olabilir.

MT5 sunucusunun kendisinin sıfır pingli bir makinede oluşturulduğuna inanma eğilimindeyim. Ancak %100 garanti için açıklama gerektiriyor. Ancak, yukarıdakiler sunucunuzda bile bir sorun olduğunu gösterdi.

 
fxsaber :

TP emirlerinin yerine getirilmesi konularını incelerken, bazı TP emirlerinin, onları kabul eden onay işaretlerinin önemli ölçüde gerisinde bırakılarak oluşturulduğunu fark ettim.

Bilgilendirme, bu durumun sadece farklı brokerlerde değil, İşlem Sunucusu ile aynı makinede bulunan Terminal'de ticaretin gerçekleştiği bir durumda da tekrarlandığını gösterdi. Onlar. çok düşük ping ve Ticaret Sunucusu için tek ticaret hesabı.

Sonuçları hesaplarınızdan paylaşmanızı rica ediyorum. MT5'in geliştirilmesine katkıda bulunun!

Çok küçük bir ayrıntıyı "unuttunuz" - 58 bin siparişi kontrol ettiniz ve 300 ms için yalnızca bir aykırı değer buldunuz. Ve bu (58.000'de 1'i) bu tür kontroller sırasında açıkça vurgulanmalıydı.

Geçen sefer olduğu gibi, tek aykırı değerlere bakıp bunun normal bir davranışmış gibi davrandığı milyonlarca kontrol vardı.


Sunucu günlüklerini kontrol ettik ve MetaQuotes-Demo demo sunucusuna sahip sanal makinemizin o saniyelerde (2020.09.30 19:07'de 4 saniye boyunca) açıkça fiziksel olarak hasta olduğu açıktı, çünkü yaklaşık 15 milyon hesap üzerinde dönüyordu. o an ve yaklaşık 2 milyon açık pozisyon ve buna paralel olarak komşu sanal makinelerde ve hipervizörde başka bir şey oluyordu.

Her durumda, tek emisyonlar her zaman herhangi bir sistemde olmasına rağmen, anlamaya devam edeceğiz.