Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
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.
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.
bir darboğaz bulmak için komisyoncu ile birlikte
Aynı fiyata ve farklı lotlara sahip iki limit vardır. Aktivasyon tetikleme dizisindeki sıralarını ne belirler?
Bu soruya birkaç cevabım var.
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ı.
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.
OnTick, ticaret sunucusunda bir onayın kaydedilmesinden birkaç milisaniye sonra tetiklenir.
Sonuç.
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.
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.
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.
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.
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.