Kendi kağıt üzerinde işlem sistemimizde ölçtüğümüz 4 sayı: tek bir strateji, 1 dakikalık BTCUSDT sürekli vadeli işlem sinyalleri, 31 gün ve 1,418 emir. Bar kapanışından emrin borsa tarafından onaylanmasına kadar geçen medyan süre: 195 ms. 99. yüzdelik dilim: 2,970 ms. Gerçekleşen volatilitenin en yüksek olduğu dakikaların %1'indeki medyan: 840 ms. Önceki yılın büyük bölümünde backtest yapılandırmasında duran gecikme değeri ise: 0.
Bu sayıların 3'ü sıkıcı. Sıfırın yanlış olduğunu herkes bilir, sonunda herkes onu başka bir değerle değiştirir ve bu değer de neredeyse her zaman birinin içgüdüleriyle seçtiği sabit bir sayıdır. 100 ms, 250 ms, “tedbirli olalım, 500.” Gerçekten önemli olan sayı 840; çünkü gecikmenizin piyasanın durumuna bağlı olduğunu, gecikmenin patladığı piyasa koşullarının da sinyalinizin bir şey bulduğunu sandığı koşullarla aynı olduğunu gösteriyor.
195 milisaniye nereye gidiyor
İşte her aşamadaki tekdüze saat zaman damgalarını kaydederek ölçtüğümüz tam bütçe. Sunucu, AWS'nin ap-northeast-1 bölgesinde; borsanın uç noktalarıyla aynı bölgede. Bir perakende yatırımcı kurulumunun, borsaya yakın sunucu kullanmayan en iyi hâli bu sayılır.
| Aşama | p50 | p95 | p99 |
|---|---|---|---|
| Bar kapanışı → WS kline-closed olayının alınması | 128 ms | 402 ms | 1,940 ms |
| Ayrıştırma + özellik durumunun güncellenmesi | 3 ms | 9 ms | 28 ms |
| Karar: model değerlendirmesi + risk kontrolleri | 11 ms | 22 ms | 60 ms |
| Emrin gönderilmesinden borsa onayına | 47 ms | 180 ms | 1,100 ms |
| Uçtan uca (toplanmadı, ölçüldü) | 195 ms | 690 ms | 2,970 ms |
İlginç kısma geçmeden önce aklınızda bulunsun: medyanlar toplanmıyor. 128 + 3 + 11 + 47 = 189, oysa uçtan uca ölçülen medyan 195. Yüzdelik dilimler toplanabilir değildir; gecikme tahmininizi aşama başına p99 değerlerini toplayarak kurarsanız gerçek p99 olan 2,970 ms yerine 3,128 ms bulursunuz. Burada yakın sonuç veriyor; aşamalar ters yönde ilişkili olduğunda ise büyük ölçüde yanılıyor. Tüm yolu ölçün.
İkinci olarak, ilk satıra bakın. Medyan bütçenin üçte ikisi, borsanın barın kapandığını bildirmesini beklerken geçiyor. Ağda değil, kodunuzda değil, emir yönlendirmede değil. Borsa işlemleri kline'larda topluyor, dakikanın bittiğine karar veriyor ve veriyi iletiyor. Bu iletinin önünde bir kuyruk var ve o akışa abone olan herkes bu kuyruğu paylaşıyor.
840
Bu 1,418 emrin her birini, sinyali üreten dakikanın gerçekleşen volatilitesine göre gruplandırınca dağılım epey değişiyor.
| Sinyal barındaki volatilite dilimi | Emir sayısı | Uçtan uca p50 | Uçtan uca p99 |
|---|---|---|---|
| En düşük çeyrek | 201 | 141 ms | 488 ms |
| Ortadaki 2 çeyrek | 796 | 183 ms | 1,210 ms |
| En yüksek çeyrek | 407 | 312 ms | 2,880 ms |
| Tüm dakikaların en yüksek %1'i | 14 | 840 ms | 4,100 ms |
Tüm aşamalar aynı anda yavaşlıyor; gecikme bu yüzden katlanıyor. Borsanın toplama ve yayın kuyruğu, eşleştirme motorunun yükünden etkileniyor. İçinde 11,000 işlem olan bir dakikanın verisi, 600 işlem olan bir dakikaya göre daha geç iletiliyor. Aynı zaman aralığında kendi süreciniz de daha fazla derinlik güncellemesi ve işlem kaydıyla uğraşıyor; genelde 3 ms süren özellik güncellemesi 28 ms sürüyor. REST emir yolu, herkesin panik hâlinde verdiği emirlerle yarışıyor ve arada bir, tek başına tam 1 saniyeye mal olan 503 yanıtları ve yeniden denemeler görmeye başlıyorsunuz. Örneğimizde sinyal barındaki işlem sayısıyla uçtan uca gecikme arasındaki korelasyon katsayısı 0.41'di. Çok yüksek değil; sabit bir değeri işe yaramaz kılmaya yetiyor.
İlk elemeden geçen stratejiler çoğunlukla kırılma, dönüş, fiyat uyumsuzluğu ve likidasyon zincirleri üzerinden işlem yapanlar. Gecikmenin en kötü olduğu dilimde tetikleniyorlar. Yalnızca dakikada 40 bps'lik hareket olduğunda tetiklenen bir momentum sinyali, yapısı gereği sisteminizin en yavaş hâliyle karşılanacak şekilde kurgulanmış demektir.
Bir keresinde her gece yaklaşık aynı saatte ortaya çıkan 3.6 saniyelik bir uç değerin peşinde bir gün harcadık. Sorun logrotate'tı: sürecin yazdığı dosya, aynı EBS biriminde 2 GB'lık bir dosyayı kopyalayarak sıfırlıyor ve olay döngüsünü duraklatıyordu. Piyasanın suçu yoktu. Önce ölçün, sonra piyasa mikro yapısını suçlayın.
Bu, gerçekleşen alımı nasıl etkiliyor
Beklerken fiyat kayıyor. Rastgele bir dakikada, medyanımız olan 195 ms boyunca sinyal yönünün tersine ortalama olumsuz hareket yaklaşık 1.1 bps oldu. 312 ms gecikmeli en yüksek çeyrek dakikalarda 5.8 bps; 840 ms gecikmeli en yüksek %1'lik dakikalarda ise emir emir defterine ulaşmadan önce yaklaşık 14 bps olumsuz fiyat kayması yaşandı.
BTC sürekli vadeli işlemlerinde makasın etkisi çok az: 84,000 fiyatındaki bir tik 0.012 bps, dolayısıyla zarar, makası geçme maliyetinden değil olumsuz fiyat kaymasından kaynaklanıyor. Aynı stratejiyi orta piyasa değerli bir sürekli vadeli işleme taşıdığınızda ikinci etken devreye giriyor: örneğimizde en iyi alış-satış makası sakin dakikalardaki 1.4 bps'ten en yüksek çeyrekte 6.2 bps'e çıktı ve o fiyattaki derinlik yarıdan fazla azaldı. Hepsini aynı anda ödüyorsunuz: fiyat kaymasını, genişleyen makası ve azalan derinliği. Çünkü hepsinin nedeni aynı.
Aynı 31 günü sabit 200 ms yerine her bara koşullu gecikmeyle yeniden oynattığımızda backtest'teki ortalama giriş fiyatı 3.1 bps kötüleşti; bu fark neredeyse tümüyle işlemlerin %9'unda yoğunlaştı. Backtest ile kağıt üzerinde işlem arasındaki giriş fiyatı farkı 4.2 bps'ten 0.9 bps'e düştü. Bu stratejinin örneklem içi Sharpe oranı 1.7'den 1.1'e indi; doğru sayı buydu, başından beri de öyleydi.
Peki yapılandırmaya ne koymalısınız
Tek bir sayı değil. Artık şöyle yapıyoruz:
- Belirlemeyin, örnekleyin. Simüle edilen her emir için gecikmeyi, o barın kendi etkinliğine göre koşullandırılmış ampirik bir dağılımdan çekin. İşlem sayısı ve mutlak getiri yeterlidir; ikisi de standart bir kline'da zaten bulunur. Her borsa ve emir türü için ayda bir kez uyarlayın.
- Uç değerleri koruyun. Lognormal dağılım uydurup işin bittiğini sanmayın; p99, hiçbir düzgün dağılımın taklit edemediği yeniden deneme fırtınalarında ve GC duraklamalarında ortaya çıkar. p95'in üzerindeki kuyruğu yeniden örnekleyerek ampirik yüzdelik dilimleri kullanıyoruz.
- İptaller için de gecikme uygulayın. Stop emrini yenilemek veya hedge emrini iptal etmek de aynı gecikmeye tabidir; hızlı piyasalarda iptal emriniz gerçekleşen işlemle yarışır. Simülatörünüz emirleri anında iptal ediyorsa risk modeliniz kurmacadır.
- Eski veriye karşı koruma ekleyin ve bunu simüle edin. Biz, ulaştığında barı 1.5 saniyeden daha eski olan tüm sinyalleri düşürüyoruz. Bunun gerçek bir maliyeti olan somut bir etkisi var: bazı işlemleri sessizce eliyor ve backtest'te de aynı işlemleri elemesi gerekiyor.
- Kağıt üzerinde işlem sonuçlarına göre yeniden kalibre edin. Gerçek veriyi kağıt üzerinde işlem sırasında elde edersiniz. Her emirde 4 aşamanın zaman damgalarını kaydedin ve dağılımları simülatörün varsaydıklarıyla haftalık olarak karşılaştırın.
Diğer varlık sınıflarında da aynı sorun var. ABD hisse senetlerinde konsolide işlem bandı, aracı kurumunuzun gecikmesine kendi toplama gecikmesini ekler ve aynı yapısal nedenle ileti hızı baskısı altında bu gecikme artar. Tahmin piyasalarının çoğunda emirler yalnızca REST üzerinden giriliyor; ölçümlerimizde medyan 100 ms'nin altındayken, bir sonuç açıklandığında ve herkes aynı anda geldiğinde bu süre birkaç saniyeye çıkıyor. Kripto opsiyonlarında, dayanak varlığın hareket ettiği dakikada fiyatlama yaptığınız kotasyon 2 saniye eski olabilir.
Bu hatanın genel biçimi, yürütme parametresini sinyalinizi yönlendiren aynı durum değişkeninin bir fonksiyonu olduğu hâlde bağımsız bir sabit gibi ele almaktır. Ücretler ve fonlama oranı öngörülebilir; gecikme öyle değil. Bütün bunlardan aklınızda tek bir sayı tutacaksanız, oranı tutun: p99 değerimiz medyanımızın 15 katı ve sinyallerimiz çoğunlukla p99'a yakın zamanda geliyor.
Dört aşamaya ölçüm ekleyin. Bir öğleden sonra sürer ve stratejiniz hakkında bir haftalık parametre aramasından daha fazlasını söyler.
← Tüm yazılar
