Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
Ama kütüğe bakıyorum ve kütüğe göre aynı tik 4 saniye farkla geldi.
ps
İfadeyi pek sevmiyorum - “olamaz” düşüncesi, uzun zamandır her şeyin olabileceği gerçeğine alışkınım.
Bu arada, belki bu konudan uzaktır, ancak bir kez, dünyanın yuvarlak olduğu ifadesine cevaben, aynı şey hakkında da dediler - "bu olamaz."
Genel olarak, kontrol edene kadar her zaman şüphe duyarım, sonra tekrar kontrol edeceğim ve tercihen bir başkası birkaç kez tekrar kontrol edecektir.
Kodunuz kesinlikle karışmıyor - günlüğü oluşturan, verileri işleyen nedir? ve sonra 4 saniye fark çıkıyor
Keneler zaten terminaldedir, yani zaten ağ üzerinden aktarılmıştır.
Kamu malı içindeki kodu onun yerine koyun
Ve kendin gör
Keneler zaten terminaldedir, yani zaten ağ üzerinden aktarılmıştır.
Kamu malı içindeki kodu onun yerine koyun
Ve kendin gör
Teşekkürler deneyeceğim, konuyu uzun zamandır takip ediyorum, daha çok araştırmacı olarak ilgileniyorum.
4 saniye boyunca bu kod lagul?
Buna benzemiyor
Kodda OnTick görmüyorum
Bu kod gibi görünüyor
Zamanımı koda ekledim.
OnTick() öğesinin ateşlendiği zamanı hatırlıyorum ( t_time = GetMicrosecondCount (); )
Sonra her işlev yürütülürken zaman alıyorum
Sonuç
Yani, her bir işlevin yürütme süresi 50 mikrosaniyeden azdır !
4 saniye nereden gelebilir?
Görünüşe göre iki danışman bir terminalde çalıştı ve terminalin zamanı yok
Tüm bilgileri tek bir günlükte "birleştirir", böylece yerel saati uygun gördüğü şekilde ayarlar.
Alım satım işlemlerinde kişisel olarak asenkron emirler kullanıyorum.
Gerçek şu ki (Borsa'da işlem yapma konusunda ciddiyseniz), o zaman emir defterindeki tüm değişikliklere ihtiyacınız var,
Ve bu olay ne kadar erken gelirse o kadar iyi.
Ben kendim için OnBook'a bir alternatif görmüyorum
Prensipte, doğrudan ticaret operasyonları çağrısını OnBook'tan kaldırmak mümkündür. OnBook'ta sadece bir işlem gerçekleştirme ihtiyacı için bir bayrak oluşturmanız yeterlidir, bayrağın kendisi başka bir yerde işlenir. Onlar. bir olay yaratacak olan, ancak OnBook prosedüründen çıktıktan sonra, oluşturulan bayrak tarafından işlemin kendisini başka bir prosedürde başlatın ve ardından OnBook kodunun kendisi ağır işlemlerden uzak kalacaktır. Bununla birlikte, siparişler eşzamansız olarak açılırsa ve delicesine büyük bir koşul işleme yoksa, bunun önemli gecikmelere neden olması olası değildir.
Zamanımı koda ekledim.
OnTick() öğesinin ateşlendiği zamanı hatırlıyorum ( t_time = GetMicrosecondCount (); )
Sonra her işlev yürütülürken zaman alıyorum
Sonuç
Yani, her bir işlevin yürütme süresi 50 mikrosaniyeden azdır !
4 saniye nereden gelebilir?
Görünüşe göre iki danışman bir terminalde çalıştı ve terminalin zamanı yok
Tüm bilgileri tek bir günlükte "birleştirir", böylece yerel saati uygun gördüğü şekilde ayarlar.
Belki doğru, böyle çılgın bir gecikme pek gerçek değil.
1 - MQ kendisi karar verdiğinde FLUSH çalıştı!
2 - Sabit diskle yoğun çalışma nedeniyle diske yazmanın teknik gecikmesi
Belki de yerel makinenizde zaten bir tür yazma kuyruğu var - bu oldukça gerçek, diske birkaç terabaytlık yedekleme döküldüğünde deneyim kazandım
Sadece şunları tahmin edebilirim:
örneğin, şu anda microsoft office'i paralel olarak kuruyorsanız - pencereleri güncelleyin ve İnternet'ten bir tür film kaydedin, yerelde bulunan MS SQL ile yoğun bir şekilde çalışın,
birkaç yedekleme yapın, bir düzine 4 torrente ve yoğun bir şekilde diske yazan iki veya üç düzine programa sahip olun.
Yani disk ile yoğun bir çalışma yapıldıysa logun diske yazılmasında gecikme olmuş olma ihtimali oldukça yüksek onu söylemek istiyorum.
Belki doğru, böyle çılgın bir gecikme pek gerçek değil.
1 - MQ kendisi karar verdiğinde FLUSH çalıştı!
2 - Sabit diskle yoğun çalışma nedeniyle diske yazmanın teknik gecikmesi
Belki de yerel makinenizde zaten bir tür yazma kuyruğu var - bu oldukça gerçek, diske birkaç terabaytlık yedekleme döküldüğünde deneyim kazandım
Sadece şunları varsayabilirim:
örneğin, şu anda microsoft office'i paralel olarak kuruyorsanız - pencereleri güncelleyin ve İnternet'ten bir tür film kaydedin, yerelde bulunan MS SQL ile yoğun bir şekilde çalışın,
birkaç yedekleme yapın, bir düzine 4 torrente ve yoğun bir şekilde diske yazan iki veya üç düzine programa sahip olun.
Yani disk ile yoğun bir çalışma yapılmışsa logun diske yazılmasında gecikme olması oldukça muhtemel olduğunu söylemek istiyorum.
Zamanımı koda ekledim.
OnTick() öğesinin ateşlendiği zamanı hatırlıyorum ( t_time = GetMicrosecondCount (); )
Sonra her işlev yürütülürken zaman alıyorum
Sonuç
Yani, her bir işlevin yürütme süresi 50 mikrosaniyeden azdır !
4 saniye nereden gelebilir?
Görünüşe göre iki danışman bir terminalde çalıştı ve terminalin zamanı yok
Tüm bilgileri tek bir günlükte "birleştirir", böylece yerel saati uygun gördüğü şekilde ayarlar.
bu arada - günlüğe yazarken günah işlememek için - kodda oluşturduğunuz diziye yerel saati ekleyebilirsiniz - aşağıda
Ardından günlük, terminalin günlüğü diske atmaya karar verdiği zaman ile kene veya OnBook olayının geldiğiyerel saat arasında açık bir farka sahip olacaktır.
Ve araştırma açısından daha doğru olacaktır.
Diske bağlı olması olası değildir , günlük önbelleğe yazılırken MT zamanı zaten ayarlanmıştır . Terminalin genel olarak 4 saniye boyunca düşündüğü buydu, RAM ve CPU'dan ziyade genel sistem yükü ile ilgili olabilir.
BUNDAN EMİN MİSİN ?
4 saniye???? , hayır! Gerçekten işlemcinin 4 saniye askıda kaldığını mı yoksa belleğin 4 saniyeliğine ayrılıp serbest bırakıldığını mı düşünüyorsunuz? Şaka mı yapıyorsun.
Büyük ihtimalle disk yazma sırasıdır.
Disk aygıtı bellek ve işlemciden daha yavaştır.
Ve sonra flush() , C dilinde böyle bir komut var, muhtemelen biliyorsunuzdur, uygun ve rahat olduğunda yürütülür ve daha sık disk yükleme ile ilişkili bir gecikme ile yürütülebilir.
Arabellekleri diske boşaltmanız gerektiğinde çağrılır.