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
Bu harika bir fikir gibi geliyor ve bu ipucu için minnettarım.
Ancak bununla ilgili 3 şey:
1) Yukarıda bahsettiğim gibi, "sonsuz" döngü sorunu bende de var, ancak bu başlıktan "sonsuz döngü"nün "bir olay on dakikadan uzun sürdü" için en iyi tahmin olduğunu anladığım için kabul ediyorum. kodum olabilir. Oldukça karmaşık göstergeler kullanıyorum ve (en azından öyle düşünüyorum) tanıtıcıları oluşturulurken tüm geçmişlerini hesapladıklarından, bu (yavaş bilgisayarlarda) on dakikadan fazla sürebilir.
2) Ancak! Genellikle bulutum 10-15 Dakika sonra çöktü. Ama dün gece, 8 saat boyunca mükemmel çalıştı. Kodu hiç değiştirmemiş olmama rağmen tek bir çökme yok. Garip!
3) Ve en önemlisi, çünkü yaklaşımınızla ilgili: Bir aracıyı hafızasına dayanarak reddettiğinizde, aracı (ve bunun için tüm bulut) çökmez, bunu anlıyorum. Ancak daha güçlü bir makinenin aynı parametre setini tekrar deneyeceğini sanmıyorum, bu nedenle temel olarak optimizasyon veri noktalarını kaybedersiniz, doğru muyum? Ödeyeceğimiz bedel bu mu diyeceksiniz?
İşten döndüğümde ajanlarımın hala çalışıp çalışmadığını merak edeceğim...
Merhaba Saat,
1) İlk olarak, 10 yıllık 1 milyon veri ve Göstergeler inanılmaz derecede karmaşık olan Göstergeleri kullanmıyorsanız, bu gün ve işlem gücü çağında NORMAL bir sistemde herhangi bir şeyin 5 dakika bile alacağına çok şaşırdım. . Burada normali vurgulamamın nedeni, bulutta ya aşırı yüklü olan ya da sadece kötü bir Windows (travma sonrası stres) yavaşlama mavisi vakası olan makinelerde çalışan birkaç aracı olduğundan hala şüpheleniyorum. Ve optimizasyonunuzu öldürmek için sadece bir dud ajanı alır....
2) Ben de sizinkiyle aynıydım - yani bir optimizasyon başlatıldıktan sonra, birkaç bulut aracısı sorunsuz sonuç verirdi. Ardından, 5-20 dakika veya bazen biraz daha uzun bir süre sonra, bir temsilci korkunç hatayı ve BANG - optimizasyonun sonunu atar. Ayrıca, sorunsuz bir şekilde tamamlandığı zaman zaman optimizasyonu da yaptım. Ajanların günlük dosyalarına, sistem ayrıntılarına, CPU kullanımına vb. erişiminiz olmadığı için neler olup bittiğini görebilmek için çok sinir bozucu.
3) Bu çok ilginç bir noktaya değindin. Bazı şeyleri anladığım kadarıyla, optimize edici yalnızca belirli bir parametre kombinasyonunun sonuçlarını aldığında "kullanılan" belirli bir parametre kombinasyonunu dikkate alır, ancak bunda yanılmış olabilirim. Belki MetaQuotes'taki biri bu nokta hakkında yorum yapabilir?
Her neyse, umarım ilerleme kaydediyorsundur! :)
32G'den daha az ram'e sahip olanları reddettiğinizde , kaç temsilci kullanılabilir ?
Merhaba,
Tüketici tipi PC'ler için büyük miktarda RAM gibi görünüyor, ancak bulutun bu özelliklere sahip makineleri bulmakta herhangi bir sorunu yok gibi görünüyor. Bir optimizasyon başlattığımda, optimize edici ilk 64 aracıyı kolayca bulur ve ardından oldukça hızlı bir şekilde 128'e yükselir (elbette parametre seti konfigürasyonuna bağlı olarak). Başlangıçta 8 GB denedim - optimizasyon daha uzun sürdü ve genellikle tamamlandı, ancak yine de düzenli olarak bir aracımın hatayı üretmesini sağladım ve sonuç olarak optimizasyonu öldürdüm. Daha sonra 16GB denedim - yine daha iyiydi ama kusursuz değildi. 24 GB denemekle uğraşmadım - doğrudan 32 GB'a gidip ne olduğunu göreceğimi düşündüm. :) Ve işte - kusursuz optimizasyonlar.
Çok daha fazla oynamak ve aracı yapılandırma gereksinimlerini biraz daha iyi hale getirip getiremeyeceğimi görmek istedim, ancak etrafta oynamak için ücret aldığınızda, teşvik hızla ortadan kalkar. :)
Merhaba,
Tüketici tipi PC'ler için büyük miktarda RAM gibi görünüyor, ancak bulutun bu özelliklere sahip makineleri bulmakta herhangi bir sorunu yok gibi görünüyor. Bir optimizasyon başlattığımda, optimize edici ilk 64 aracıyı kolayca bulur ve ardından oldukça hızlı bir şekilde 128'e yükselir (elbette parametre seti konfigürasyonuna bağlı olarak). Başlangıçta 8 GB denedim - optimizasyon daha uzun sürdü ve genellikle tamamlandı, ancak yine de düzenli olarak bir aracımın hatayı üretmesini sağladım ve sonuç olarak optimizasyonu öldürdüm. Daha sonra 16GB denedim - yine daha iyiydi ama kusursuz değildi. 24 GB denemekle uğraşmadım - doğrudan 32 GB'a gidip ne olduğunu göreceğimi düşündüm. :) Ve işte - kusursuz optimizasyonlar.
Çok daha fazla oynamak ve aracı yapılandırma gereksinimlerini biraz daha iyi hale getirip getiremeyeceğimi görmek istedim, ancak etrafta oynamak için ücret aldığınızda, teşvik hızla ortadan kalkar. :)
Metaquotes'tan biraz geri dönüş almak ilginç olurdu. 16G ram'li bir makine bazı optimizasyonları çalıştırmak için yeterli değilse, araştırılması gereken bir şey var. İyi anladıysam, optimizasyonunuzu yerel olarak çalıştırdığınızda herhangi bir probleminiz yok, o zaman bulutu kullanırken neden bu kadar çok belleğe ihtiyaç var?
Kesinlikle hiçbir fikrim yok. Yerel makinem, MT5'in 8 yerel aracı yüklediği 8 GB i7 işlemcili bir makinedir (açıkçası yalnızca 4 çekirdekli bir işlemcidir, ancak Hyper-Threading, Windows ve dolayısıyla MT5 onu elbette 8 çekirdekli bir işlemci olarak görür). Bir optimizasyon gerçekleştirilirken, ajanların her biri yaklaşık 400 MB bellek kullanıyor gibi görünüyor, bu da 8 ajan için yaklaşık 3,2 GB gerekli belleğe karşılık geliyor. 32 GB'a yakın hiçbir yerde ....
Düşündüğüm diğer şey, aslında bu sorunun temel nedeni olabilir, "kötü" bir bulut aracısının tüm optimizasyonu sonlandırmasıdır. Gerçekte olabilecek şey, bulut sunucusu aracıları bir optimizasyon işi için tahsis ettiğinde (bellek gereksinimleri belirtilmeden), aynı "kötü" aracıların seçilmesi/seçilmesidir. OnInit() içinde bellek gereksinimleri belirtildiğinde, üzerinde çalıştıkları kutular gereksinimleri karşılamadığından ve yalnızca iyi aracılar seçildiğinden "kötü" aracılar atlanır. Bunu düşününce, bunun muhtemelen daha fazla olduğundan şüpheleniyorum.
Ve evet, bu sorunu MetaQuotes'a kaydettim ama henüz bir şey duymadım.
OnInit (veya başka bir işlev) yavaş bir aracıda bile 10 dakikadan fazla yürütülürse, MQL5 Bulut Ağı için zararlı sonsuz bir döngü olarak kabul edilir (Yerel ve uzak aracılar için böyle bir sınırlama olmadığını unutmayın).
Bu tür durumlar için OnInit işlevi için INIT_AGENT_NOT_SUITABLE dönüş kodunu uyguladık. Bunu kullanarak, bir bulut ağı kullanıcısı, bir test çalıştırmasının en başında uygun olmayan aracıları kontrol edebilir ve reddedebilir.
Bu yorumu Servis Masası biletinize resmi bir cevap olarak kabul edebilirsiniz. Yukarıda verilen bilgilerden haberdar olduğunuzu biliyoruz.
Ek olarak: Her durumda, herhangi bir işlevin yürütülmesi en yavaş PC'de bile 10 dakikadan fazla sürerse anormal, etkisiz ve uygun olmayan olarak kabul edilir.
OnInit (veya başka bir işlev) yavaş bir aracıda bile 10 dakikadan fazla yürütülürse, MQL5 Bulut Ağı için zararlı sonsuz bir döngü olarak kabul edilir (Yerel ve uzak aracılar için böyle bir sınırlama olmadığını unutmayın).
Bu tür durumlar için OnInit işlevi için INIT_AGENT_NOT_SUITABLE dönüş kodunu uyguladık. Bunu kullanarak, bir bulut ağı kullanıcısı, bir test çalıştırmasının en başında uygun olmayan aracıları kontrol edebilir ve reddedebilir.
Bu yorumu Servis Masası biletinize resmi bir cevap olarak kabul edebilirsiniz. Yukarıda verilen bilgilerden haberdar olduğunuzu biliyoruz.
Ek olarak: Her durumda, herhangi bir işlevin yürütülmesi en yavaş PC'de bile 10 dakikadan fazla sürerse anormal, etkisiz ve uygun olmayan olarak kabul edilir.
Merhaba MetaQuotes,
Öncelikle, yorumlarınız için çok teşekkürler - çok takdir ediyorum.
Karşılaştığım sorun (ve görünüşe göre bu gönderiye geri bakarsanız diğerleri), yerel aracılarım kullanılarak bir optimizasyon gerçekleştirildiğinde, optimizasyonun iyi çalışmasıdır - yani her bir aracıdaki "tamamlanma yüzdesi" durumu, optimizasyon arttıkça istikrarlı bir şekilde artar. ilerler. Expert'imdeki OnTick() olay işleyicisi, tamamlanması bir dakikadan (bırakın 10 dakika) bile fazla sürecek herhangi bir kod içeriyorsa, bu "tamamlanma yüzdesi" yüzdeleri kesinlikle bu zamanlarda duraklar mı? Kodum, bulut aracısı hatalarının ima ettiği sonsuz döngü biçimlerini içeriyorsa, bu durum yüzdelerinde 10 dakikalık (veya daha fazla) duraklamalar görmem gerekmez mi?
Pekala, Uzmanımı saatlerce yontarak geçirdikten sonra, OnInit() veya OnTick() "sonsuz döngü" hatalarıyla ilgili sorunların bir/kaynağını buldum - bu SymbolInfoInteger() komutudur. SymbolInfoDouble() veya SymbolInfoTick() aynı sorunlara neden olup olmadığını henüz daha fazla deneme şansım olmadı mı bilmiyorum. Herhangi biri bunu denemek isterse, bulut aracılarını kullanarak Optimize Edici'de aşağıdaki Expert'i çalıştırın:
OnInit() veya OnTick()'i test etmek isteyip istemediğinizi seçin, var1 ve var2'ye yaklaşık 1000 kombinasyon oluşturmak için yeterli başlatma/adım/durdurma değerleri verin (muhtemelen daha azı yapacaktır ama ben bunu kullanıyorum) ve ateşleyin optimize edici. Yaklaşık 10 dakika içinde "sonsuz döngü algılandı" hatasını göreceksiniz.
Ah, ve "ExpertRemove()" öğesini OnTick() öğesinin sonuna koymamın nedeni , hatayı oluşturmak için yalnızca bir OnTick() yinelemesi gerektiğini göstermekti.
Söylemeye gerek yok, bunu servis masasına da bildirdim...
Bu sorunu onaylayabilirim:
2013.05.20 14:22:31 MQL5 Cloud Europe 2 genetik geçiş (0, 22), 602 saniyede "OnInit işlevinde sonsuz döngü algılandı, uzman MQL5 Cloud Network tarafından reddedildi" hatasıyla test edildi (PR 140)