SL/TP siparişlerinin kabulü - sayfa 2

Yeni yorum
 
Bu bilgi tüm mega-HFT-shniks MT-shny'ye gönderilecek, sadece şaka, sadece şaka)) Ucuzluğun maliyeti.
 
fxsaber :

Başka bir başlıkta, Terminal'in bile çok sayıda faktörden yavaşladığı defalarca belirtildi. Sonuç olarak, çok daha karmaşık bir Ticaret Sunucusu daha da yavaşlayacaktır. Bununla birlikte, algoritmik optimizasyonun hala mümkün olduğunu umuyorum. 5 ms gecikme bile zaten çok kötü. Yüzlerce milisaniye hakkında ne söyleyebiliriz.

Demoda ne var çok ilginç değil (orada herhangi bir eklentide hata ayıklayabilir, yeni donanımı test edebilirsiniz, ...).

Ve canlı hesaplarda maksimum 17 ms buldum (Bunun yeterli olmadığını söylemiyorum, sadece 30 saniye ile karşılaştırılamaz).

Bu nedenle, özel sunucu ayarları şüphesi.

 
Andrey Khatimlianskii :

Demoda ne var çok ilginç değil (orada herhangi bir eklentide hata ayıklayabilir, yeni donanımı test edebilirsiniz, ...).

Ve canlı hesaplarda maksimum 17 ms buldum (Bunun yeterli olmadığını söylemiyorum, sadece 30 saniye ile karşılaştırılamaz).

Ne yazık ki, kaç siparişin kontrol edildiğini göstermediler.

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

SL/TP siparişlerinin kabulü

fxsaber , 2020.11.25 01:23 

Total Orders (from 2020.11 . 01 00 : 00 : 00 ) = 21725 , calculated = 10465
Calculation time = 00 : 04 : 33.609 , Performance = 38.0 orders/sec.

Bu nedenle, özel sunucu ayarları şüphesi.

Komisyoncu sorunu onayladı ve sorunu bulup düzeltebildi (hafta sonundan sonra mevcut olacak). Ama bunun MT5 yüzünden olup olmadığını söylemek zor.


Ama MT5 yönünde taş atmak tam da bu durumda olabilir.

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

SL/TP siparişlerinin kabulü

fxsaber , 2020.11.25 00:47

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ı ile.



Terminal ve Sunucu aynı makinede. Sıfır yükleme. Yeni bir çekim böyle bir uyarı aldı. 

Accepted Tick 2020.11 . 25 16 : 05 : 11.522 10.15469 10.15668
Accepted Length = 4 ms.
Order 212 ORDER_TYPE_SELL EURSEK 2020.11 . 25 16 : 05 : 11.526 10.15462 ORDER_REASON_TP ORDER_STATE_FILLED


Sunucu günlüğü. 

2020.11.25 16:05:11.526    '': take profit triggered #168 buy 0.01 EURSEK 10.19022 tp: 10.15462, activation price 10.15469 [#212 sell 0.01 EURSEK at 10.15462][10.15469 / 10.15668]


Sunucudaki onay işaretini kabul edin.


Komut dosyası verilerinin bir sorun olduğuna dair tam onay. Sunucunun içinde sıfır yükte 4 ms'lik bir gecikme oldu.

 
Andrei Trukhanovich :

fxsaber'dan bir beyin patlaması daha.

Ne kadar zaman öldürdüğünüzü fark ettiğinizde özellikle güçlü bir şekilde hissedilir. Ve bunu senin için kimsenin yapmayacağı.
 

Sunucuda gerçekten bir sorun var gibi görünüyor. Bu bir MT5 demo hesabıdır

 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Total Orders (from 2020.01 . 01 00 : 00 : 00 ) = 5417 , calculated = 755
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  Calculation time = 00 : 00 : 14.656 , Performance = 51.0 orders/sec.
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  ServerName: RannForex-Server
 2020.11 . 25 16 : 58 : 07.787 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Last Tick 2020.11 . 23 19 : 59 : 30.634 104.341 104.341
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Tick 2020.11 . 23 19 : 58 : 57.044 104.336 104.336
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Accepted Length = 33592 ms.
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  Order 1747932 ORDER_TYPE_SELL USDJPY 2020.11 . 23 19 : 59 : 30.636 104.336 ORDER_REASON_TP ORDER_STATE_FILLED 2020.11 . 23 19 : 59 : 30.658 , Position 1747924 created 2020.11 . 23 19 : 58 : 35.556 , StopLevel = 0
 2020.11 . 25 16 : 58 : 07.798 OrderCheck (USDJPY,H1)  
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Orders ( 3 ) before 1747932 with PositionID = 1747924 :
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  ------------------------
 2020.11 . 25 16 : 58 : 07.799 OrderCheck (USDJPY,H1)  Checked Orders = 0

Aynı komisyoncu ile gerçek bir hesapta , komut dosyası sıfır sonuç döndürür. Hesapta 3000'den fazla işlem.

 
Enrique Dangeroux :

Aynı komisyoncu ile gerçek bir hesapta , komut dosyası sıfır sonuç döndürür. Hesapta 3000'den fazla işlem.

Bu şüpheli. Hesaplarımın hiçbir yerinde gecikme olmadığını bulamadım.

 

Bunun ilgili olup olmadığından emin değilim. ama çok şey alıyorum 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

Konum değişikliği Take'i tetikleyen hatalar. Ateş al, birkaç kez reddet, sonra kilitleniyor, güvenli tarafta olmak ve çarpmak için tp'yi sıfıra değiştiriyorum.


Değiştirmeden önce bunu kontrol ediyorum

 if ( OrderCloseReason() >= ( int ) ORDER_REASON_SL )

durum donmasın diye.

 
fxsaber :

Bu şüpheli. Hesaplarımın hiçbir yerinde gecikme olmadığını bulamadım.

Ben de aynı şeyi düşündüm, ancak daha fazla araştırma, Take tarafından kapatılan sadece 100 kadarının olduğunu gösterdi.

Yani, küçük bir örneklem boyutuna.

 

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

SL/TP siparişlerinin kabulü

Enrique Dangeroux , 2020.11.25 17:20

Bunun ilgili olup olmadığından emin değilim. ama çok şey alıyorum 

2020.11.25 16:52:52.992 Trades  '92810': failed modify #1758569 sell 0.02 USDJPY sl: 0.000, tp: 104.293 -> sl: 0.000, tp: 0.000 [Unknown error]

Ayrıca bu tür mesajlarda tüm günlüğüm var. Belki hafta sonundan sonra işler değişir.

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

SL/TP siparişlerinin kabulü

fxsaber , 2020.11.25 16:30

Komisyoncu sorunu onayladı ve sorunu bulup düzeltebildi (hafta sonundan sonra mevcut olacak). Ama bunun MT5 yüzünden olup olmadığını söylemek zor.

 

Ticaret platformunun bazı algoritmalarını şematik olarak düşünün. Basit olması için, yalnızca bir LP (likidite sağlayıcı) olduğunu varsayacağız.


Sınır emri.

  1. LP'den alınan fiyat, ticaret platformunun limit emrinin fiyatını karşılar.
  2. Gateway, bu limiti kısa bir sona erme süresi ile LP'ye gönderir.
  3. Limit limit hacminin bir kısmı için bir ret alırsa, o zaman Gateway, limit limit işlem süresi sırasında LP'den gelen onay değiştiyse, kalan hacim için adım 1'den itibaren her şeyi tekrarlar.

Bir limit emri yürütüldüğünde, iyi bir Ağ Geçidi (yukarıdaki algoritma ile) işlem platformunun özelliklerine bağlı değildir.

Algoritma neredeyse döngülüdür ve platformdan bağımsızdır. İstenmeyen posta koruması LP, madde 3'te yer almaktadır.


Açık bir pozisyonun TP seviyesi.

  1. LP'den kene geldi
  2. Fiyat, MT5'e yeni bir onay işareti olarak gönderilir.
  3. Pozisyon kilitli değilse ve yeni tik fiyatı TP seviyesini karşılıyorsa, MT5 kendisi ilgili bir TP emri yaratır.
  4. Gateway, bir TP emrinin doğduğunu görür, pozisyonu bloke eder ve limit emri algoritmasının 2. adımını yapar.
  5. Bir ret alırsa, MT5'te ret durumu ile geçmişe bir TP siparişi gönderir. Konumun kilidi açıldı.

Algoritma döngülü değildir ve platforma bağımlıdır. LP spam koruması var.


Gateway-MT5 bağlantısının maliyetlerini hesaba katmazsanız, bu algoritmanın iki dezavantajı vardır.

  • Bu iş parçacığında, MT5'te bir TP siparişinin doğumunun (3. maddeye bakın) gecikmeyle gerçekleştiği gösterildi. Bu nedenle, gerçekleşme olasılığı, gecikme olmaması durumundan daha düşüktür.
  • MT5'teki bir TP siparişi, yeni bir onay işareti olmadan oluşturulamaz. Bu, bir reddetme alırsak, MT5'e TP seviyesini karşılayan yeni bir onay işareti gelene kadar Ağ Geçidinin hiçbir şey yapmayacağı anlamına gelir. Ve bu nedenle, TP seviyesini yürütmeye çalışmak için değerli zaman ortadan kalkar. Ayrıca FillRate değerini düşürür.


Gelişme.

Açık bir pozisyonun TP seviyesi algoritmasındaki Akıllı Ağ Geçidi, madde 6'ya sahiptir:

6. Reddetme süresi sırasında LP'den yeni bir onay işareti alındıysa, mevcut değeri yeni bir onay işareti olarak MT5'e yeniden gönderilir - 2. adıma gidin.

Algoritmadaki bu ek adım hala LP spam koruması içerir, ancak MT5'i 3. adımı gerçekleştirmesi için kandırır. Ve yeni bir kene bekleyen değerli zaman kaybolmaz.


gerçeklik.

Bu iki algoritmadan (ikincisinde 6. maddenin bulunması durumunda bile), aşağıdaki hizalama gelir.

MT5 Limit Emri, adaşı Açık Pozisyon TP Seviyesinden daha yüksek bir Doldurma Oranına sahiptir. Bu nedenle, MT5-Hedge'de geri giderken, limit sınırının dolduğu, ancak TP adaşı olmadığı durumlarla sık sık karşılaşabilirsiniz. Bu durumda CloseBy yapılır ve uygun hacim ile limit limit yeniden ayarlanır.


Çözüm.

MT5'te Doldurma Oranını artırmak için, açık pozisyonların TP seviyelerini MT5 limit emirlerine aktarın.

12345678
Yeni yorum