Küçük bir prop trading firmasında yavaş emir gerçekleştirme: gecikmeyi bulmak için her emrin süresini ölçün, sonra bir mühendislik şirketini, bir hosting sağlayıcısını ya da aracı kurumu arayın.
Emirlerin yavaş gerçekleşmesini, emir yolunda sürenin kaybedildiği kısmın sahibi düzeltir; bu yüzden ilk iş o kısmı bulmaktır. Her emre görebildiğiniz noktalarda zaman damgası vurun; en büyük boşluk kimi arayacağınızı söyler: yazılımınızın içindeki gecikmeler için geliştiricilerinizi ya da bir mühendislik şirketini, mesafe için bir hosting sağlayıcısını, aracı kurumun kendi tarafındaki gecikmeler için aracı kurumu.
Kısa yanıt: kimseyle anlaşmadan önce her emir için karar, gönderim, aracı kurum onayı ve gerçekleşme anlarını kaydedin ve aracı kuruma ağ üzerinden gidiş-dönüş süresini ölçün. Emir sunucunuzdan çıkmadan önceki boşluk geliştiricilerinizin ya da bir mühendislik şirketinin işidir, yavaş bir ağ bir hosting meselesidir, aracı kurumun içindeki boşluk ise aracı kurumun düzeltmesi gereken bir şey ya da farklı bir yoldan bağlanmak için bir nedendir.
“Emirlerimiz çok yavaş gerçekleşiyor” ne demek?
Bu şikâyet dört farklı soruna işaret edebilir ve her birinin sahibi farklıdır.
- Her emir yavaştır. Gecikme sakin bir sabahta da piyasa açılışında da aşağı yukarı aynıdır. Bu, her emrin ödediği bir bedele işaret eder: mesafe, aracı kuruma bağlanma şekliniz ya da kendi yazılımınızın her emir çıkmadan önce yaptığı yavaş işler gibi
- Emirler piyasa yoğunlaşana kadar hızlıdır. Açılışta ya da haber geldiğinde gecikme fırlar. Emirler bir yerde kuyrukta bekliyordur: yetişemeyen bir programın, bir mesaj limitinin ya da başka işlerle meşgul bir makinenin arkasında
- Emirler zamanında ulaşır ama geç gerçekleşir. Limitli bir emir, biri karşı taraftan işlem yapana kadar defterde bekler ve hızlı bir piyasada fiyat uzaklaşır. Zaman damgaları emrin geç kalıp kalmadığını gösterir. Hangi fiyatın mevcut olduğunu ise gösteremezler
- Ekran geride kalır. İşlem ekranındaki fiyatlar gecikirse trader'lar geç tıklar ve suçu emirlerin gerçekleşmesine atar. Bu bir piyasa verisi sorunudur ve bu blogda ayrı bir yazıda ele alınıyor
Bu dördünü ancak gerçek emirlerin ve bu emirlerin tepki verdiği fiyatların zaman damgaları birbirinden ayırabilir. Hangi günlere bakacağınızı trader'ların şikâyetlerine göre seçin.
Sistemimizle borsa arasında milisaniyeler nereye gidiyor?
Bir emir giderken dört bölümden geçer; onay ise aracı kurumdan döner, bazen ancak borsa emri kabul ettikten sonra.
- Sizin tarafınız. Strateji ya da trader karar verir, emir oluşturulur, kendi kontrolleriniz çalışır ve emir gönderilir. Gecikmeler gönderimden önce yapılan işlerden, program duraklamalarından, ağ ayarlarından ya da meşgul bir makineden gelir. Bu kısmı geliştiricileriniz ya da bir mühendislik şirketi değiştirebilir
- Hat. Emir sunucunuzdan aracı kurumun giriş noktasına gider. Buradaki gecikmeyi mesafe, internet yönlendirmesi ve VPN gibi ek ara duraklar ekler. Bir hosting ya da colocation sağlayıcısı veya bir ağ mühendisi bunu kısaltabilir
- Aracı kurum. Ağ geçidi emri alır, kontrollerini çalıştırır ve borsaya yönlendirir. Gecikmeler aracı kurumun kendi sistemlerinden ve zorunlu kontrollerinden gelir. Bunları yalnızca aracı kurum değiştirebilir; siz nasıl bağlanacağınızı ve hangi aracı kurumla çalışacağınızı seçersiniz
- Borsa. Eşleştirme motoru emri kabul eder ve onayı geri gönderir. Burada çok az süre harcanır: Nasdaq, yüksek hızlı 10G colocation ağında emirden onaya gidiş-dönüşün 50 mikrosaniyenin altında olduğunu belirtiyor. Anlaşabileceğiniz hiç kimse bu kısmı değiştiremez; yalnızca ona yaklaşabilirsiniz
ABD'de aracı kurumun kontrolleri isteğe bağlı değildir. SEC Rule 15c3-5, piyasaya erişimi olan bir aracı kurumun “önceden belirlenmiş uygun kredi ya da sermaye eşiklerini aşan emirlerin girişini engellemesini” ve “uygun fiyat ya da miktar parametrelerini aşan” emirleri reddetmesini şart koşar. Aynı kural bu kontrolleri “aracı kurumun ya da dealer'ın doğrudan ve münhasır kontrolü altına” koyar. Aracı kuruma kontrollerinin ne kadar sürdüğünü sorabilirsiniz, ama kural onları kapatmasına izin vermez.
Sürenin nerede kaybedildiğini nasıl buluruz?
Her emir için dört zaman damgası kaydedin:
- Karar: strateji ya da trader emri göndermeyi seçti
- Gönderim: emir sunucunuzdan çıktı
- Onay: aracı kurumun emri kabul ettiğine dair teyidi sunucunuza ulaştı
- Gerçekleşme: gerçekleşme bildirimi geldi
Karardan gönderime kadarki süre sizin yazılımınızdır. Gönderimden onaya kadarki süre, gidiş ve dönüşte hat ile aracı kurumdur; aracı kurum borsayı bekliyorsa buna borsa da eklenir. Hangisinin geçerli olduğunu aracı kurumunuza sorun. Defterde bekleyen bir emir için onaydan gerçekleşmeye kadarki süre çoğunlukla piyasadır.
Bir rakamı daha ölçün: sunucunuzdan aracı kurumun giriş noktasına ağ üzerinden gidiş-dönüş süresi. Bu rakam, gönderimden onaya kadarki sürenin ne kadarının hatta geçtiğini gösterir.
FIX, FIX Trading Community tarafından sürdürülen, trading için bir mesaj standardıdır. FIX üzerinden bağlanıyorsanız, aracı kurumun mesajları iki zaman damgası taşır: biri mesajın gönderildiği anı, diğeri mesajın bildirdiği olayın gerçekleştiği anı gösterir. FIX spesifikasyonu bu alanlara SendingTime ve TransactTime der; hangisini kimin saatinin belirlediğini aracı kurum size söyleyebilir. Kendi zaman damgalarınızın yanında bu alanlar, gidiş-dönüşün hangi kısmının kimin tarafında geçtiğini gösterir.
Zaman damgalarınızı aracı kurumunkilerle karşılaştırmak ancak iki saat de doğruysa işe yarar. FINRA Rule 6820, Consolidated Audit Trail'e raporlama yapan aracı kurumların iş sistemlerindeki saatleri NIST atom saatinden en fazla 50 milisaniye sapacak şekilde tutmasını şart koşar. AB kurallarına göre yüksek frekanslı algoritmik işlem yapan bir işlem merkezi üyesi, saatlerini UTC'den en fazla 100 mikrosaniye sapacak şekilde tutmak zorundadır. 50 milisaniye sapmasına izin verilen bir saat, birkaç milisaniyelik bir gecikmenin nerede olduğunu bulamaz.
Gönderim ve onay anlarının ikisi de sizin saatinizden okunur; bu yüzden aradaki süre için senkronizasyon gerekmez. Oradan başlayın. Bu gidiş-dönüş kısaysa ve emirler yine de yavaş görünüyorsa, kendi yazılımınıza bakın. Uzunsa, önce yanıt geldiğinde programınızın duraklamış ya da meşgul olmadığını kontrol edin; değilse, süre yazılımınızın dışında harcanıyordur.
Sonra en yavaş emirlere bakın. Bir haftalık emirleri gidiş-dönüş süresine göre sıralayın ve yüz emirden yalnızca birinin aştığı süreyi not edin; aynısını açılıştan sonraki ilk dakikalar ve planlı haber açıklamalarının çevresi için de yapın. Ortalama, trader'ların şikâyet ettiği anları gizler.
Küçük bir prop firmada emirlerin gerçekleşmesini ne yavaşlatabilir?
Önce şu altı nedene bakın.
- Aracı kurumun API'si, çalıştırmanız gereken bir programdan geçer. Örneğin Interactive Brokers, TWS API'sini “Trader Workstation ya da IB Gateway'e bağlantıya” dayalı olarak tanımlar; yani her emir önce bu programlardan birinden geçer. Dokümantasyonu, istemci bağlantısı başına varsayılan olarak “saniyede 50 istek” sınırı koyar ve bazı durumlarda bu hızın üzerinde “bazı emirlerin kuyruğa alınıp gecikebileceği” uyarısında bulunur. Bu durum için Interactive Brokers, FIX API'sine geçmeyi önerir. Darboğazınız buysa, aracı kurumunuza başka nasıl bağlanabileceğinizi sorun
- Sunucu, emirlerin gittiği yerden uzaktadır. Bir ofis makinesi ya da uzak bir bulut bölgesi mesafenin bedelini her emirde iki kez öder, gidişte ve dönüşte; hiçbir kod değişikliği bunu ortadan kaldırmaz. En kısa mesafe için Nasdaq, müşterilerine “sunucularını ve ekipmanlarını Nasdaq Veri Merkezi'nin içine yerleştirme” imkânı sunar. Colocation için ödeme yapmadan önce sunucunuzdan aracı kurumun giriş noktasına ağ üzerinden gidiş-dönüş süresini ölçün
- Emir gönderilmeden önce yavaş işler çalışır. Emri bir veritabanına yazmak, bir log satırının diske ulaşmasını beklemek ya da işleme izin verilip verilmediğini başka bir servise sormak her emre bir bekleme ekler. Veritabanı ya da disk meşgul olduğunda bu bekleme uzar. Emrin ihtiyaç duyduğunu bellekte tutun, kayıtları emir çıktıktan sonra yazın
- Ağ ayarları küçük mesajları bekletir. Bir emir küçük bir mesajdır. Linux kılavuzuna göre TCP_NODELAY adlı soket seçeneği ayarlı değilse, giden veri “gönderilecek yeterli miktar birikene kadar” tamponda tutulur. Geliştiricileriniz bu seçeneğin ayarlı olup olmadığını kontrol edebilir
- Program duraklar. Bazı garbage collector'lar belleği temizlerken programın tamamını durdurur. İşinin çoğunu program çalışırken yapan Go garbage collector'ının bile “kısa stop-the-world duraklamaları” vardır ve Go garbage collector rehberi bunları olası gecikme kaynakları arasında sayar. Bir emir çıkarken duraklama gelirse emir geç çıkar. Aynı makinede çalışan grafikler, backtest'ler ya da raporlar da benzer bir etki yaratır; çünkü emir işlemciyi bekler
- Aracı kurumun kendi yolu yavaştır. Ağ geçidi, kontrolleri ve yönlendirmesi her emrin yolunda durur ve içini göremezsiniz. Giriş noktasının nerede olduğunu, hangi bağlantı türlerini sunduğunu, hesabınıza hangi mesaj limitlerinin uygulandığını ve emirleriniz için kendi zaman damgalarını paylaşıp paylaşmayacağını sorabilirsiniz
Her neden nasıl düzeltilir ve iş ne kadar büyüktür?
- Karardan gönderime geçen süre her emirde uzundur. Yavaş işleri emir yolundan çıkarın ve ağ ayarlarını kontrol edin. Yapılacak iş kodunuzda bir değişikliktir, bazen tek bir ayar
- Karardan gönderime geçen süre yoğun anlarda fırlar. Emrin neyi beklediğini bulun: bir duraklama, bir kuyruk, paylaşılan bir makine. Yapılacak iş bir kod ya da hosting değişikliğidir; tasarımın kendisi kuyruk oluşturuyorsa emir yolunun yeniden kurulmasıdır
- Gönderimden onaya geçen süre her emirde uzundur. Sunucuyu aracı kurumun giriş noktasına yaklaştırın ya da bağlantı türünü değiştirin. Bir hosting sözleşmesi ve taşınma ya da yeni bir bağlantı için entegrasyon işi bekleyin
- Gönderimden onaya geçen süre hacimle birlikte fırlar. Aracı kurumda ya da kendi bağlantınızda takıldığınız limiti bulun. Aracı kurumla tek bir görüşme ya da sizin tarafınızdan daha az mesaj yetebilir
- Onaydan gerçekleşmeye geçen süre uzundur. Emir tipine ve piyasaya bakın. Bu bir mühendislik işi değildir
Önce doğrulanmış en ucuz nedeni düzeltin, yeniden kurmayı en sona bırakın. Kimse bir emrin süresini ölçmeden sistemi yeniden yazmayın ya da aracı kurum değiştirmeyin; çünkü gecikme başka bir yerde olabilir.
Yavaş emir gerçekleştirmeyi düzeltmek için bize kim yardım edebilir?
Kimin yardım edebileceği sürenin nereye gittiğine bağlıdır.
- Aracı kurumunuz. Kendi tarafını görebilen ve değiştirebilen tek taraf odur. Emirleriniz için kendi zaman damgalarını, limitlerini ve bağlantı seçeneklerini isteyin
- Bir hosting ya da colocation sağlayıcısı veya borsanın bağlantı ekibi. Aracı kurumun ya da borsanın giriş noktasına yakın yer kiralar, oraya giden ağ hatlarını da satarlar
- Lisansladığınız bir trading platformu üzerinden işlem yapıyorsanız, o platformun sağlayıcısı. Platformun iç yapısını yalnızca sağlayıcı değiştirebilir; bu yüzden zaman damgalarınızı ona götürün
- Trading sistemleri üzerinde çalışan bir mühendislik şirketi. Yolun tamamını ölçer, ardından sizin taraftaki parçaları değiştirir ya da yeniden kurar; örneğin emir yolunu, risk kontrollerini ve aracı kuruma bağlantıyı
- Varsa kendi geliştiricileriniz. Dört zaman damgasıyla yetkin bir geliştirici, yolun sizin tarafınızdaki her nedeni kontrol edebilir
Kiminle anlaşırsanız anlaşın, önce şu dört soruyu sorun:
- Bir düzeltme önermeden önce ölçüm yapacak mısınız ve tam olarak neyin zaman damgasını kaydedeceksiniz?
- Rapor bizim tarafımızı, hattı ve aracı kurumu birbirinden ayıracak ve yalnızca ortalamayı değil, en yavaş emirleri de gösterecek mi?
- Verdiğiniz her rakam için: hangi yüzdelikte, hangi yük altında, hangi tarihte?
- Gecikmenin aracı kurumda olduğu ortaya çıkarsa bize ne söyleyeceksiniz?
Son soruya verilen yanıt yine de sisteminizin yeniden kurulmasıysa, aramaya devam edin.
amBrain nerede devreye girer?
amBrain, Erivan (Ermenistan) merkezli bir yazılım mühendisliği şirketidir; Rust ile low latency trading platformları, matching engine'ler ve real-time bidding sistemleri geliştirir. amBrain; trading, bahis ve reklam teknolojisi alanlarındaki yavaş sistemleri teşhis eder: çalışan platform uçtan uca ölçülür ve rapor, sürenin nereye gittiğini açıkça gösterir.
amBrain, algoritmik trading altyapısı geliştirir: emir gerçekleştirme, piyasa verisi ve işlem öncesi risk kontrolleri. Trading alanındaki işleri arasında trading terminali geliştirme, emir yönetim sistemleri ve FIX protokolü ile borsa entegrasyonu yer alır. amBrain, başka bir ekiple takılıp kalmış projeleri devralır ve üretim ortamına taşır. Üç format: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler.
Henüz başındaysanız, dört zaman damgasını normal bir günde ve yoğun bir günde kaydedin. Kimi ararsanız arayın, amBrain'i ya da bir başkasını, bu kayıtları yanınızda götürün; böylece ilk görüşme sürenin nereye gittiğinden başlar.
Sık sorulan sorular
- Sistemimizi Rust ile yeniden yazmak emirlerin gerçekleşmesini hızlandırır mı? Yalnızca süre yazılımınızın içinde kaybediliyorsa ve yalnızca emrin geçtiği kısımda. Rust bellek güvenliği garantilerini “bir garbage collector'a ihtiyaç duymadan” sağlar; bu da garbage collection duraklamalarını olası nedenler arasından çıkarır. Meşgul bir makine, mesafe ya da aracı kurum konusunda hiçbir şey değiştirmez
- Kodumuzu değiştirmeden ölçebilir miyiz? Evet, sisteminiz giden emirleri ve gelen teyitleri zamanlarıyla birlikte zaten logluyorsa: gönderimden onaya kadarki gidiş-dönüş süresi bu loglarda vardır
- Daha hızlı gerçekleştirme bize daha iyi fiyatlar getirir mi? Bunu kimse vaat edemez. Hız, karar ile emrin ulaşması arasındaki süreyi kısaltır; alacağınız fiyat ayrıca likiditeye, emir tipine ve bu arada piyasanın ne yaptığına bağlıdır