چهار عدد، همگی اندازه‌گیری‌شده در سامانهٔ معامله‌گری کاغذی خودمان، برای یک استراتژی، سیگنال‌های قرارداد دائمی BTCUSDT با بازهٔ 1 دقیقه، طی 31 روز و 1,418 سفارش. زمان میانه از بسته‌شدن کندل تا تأیید سفارش از سوی صرافی: 195 ms. صدک 99: 2,970 ms. میانه در 1٪ دقیقه‌هایی که بیشترین نوسان تحقق‌یافته را داشتند: 840 ms. و مقدار ثابتی که بیشترِ سال قبل در پیکربندی بک‌تست بود: 0.
سه تا از این عددها ملال‌آورند. همه می‌دانند صفر اشتباه است، بالاخره آن را با چیزی جایگزین می‌کنند و آن چیز تقریباً همیشه مقداری ثابت است که کسی از روی حس انتخاب کرده. 100 ms، 250 ms، «بیایید محتاط باشیم، 500». عددی که واقعاً اهمیت دارد 840 است، چون می‌گوید تأخیر تابع وضعیت بازار است، و وضعیت‌هایی که در آن تأخیر از کنترل خارج می‌شود همان وضعیت‌هایی‌اند که سیگنال شما فکر می‌کند چیزی پیدا کرده است.
195 میلی‌ثانیه کجا صرف می‌شود
این هم بودجهٔ کامل، اندازه‌گیری‌شده مرحله‌به‌مرحله با مُهرهای زمانی ساعت یکنواخت که در هر گام ثبت شده‌اند. سرور یک نمونهٔ AWS در ap-northeast-1 است، در همان منطقهٔ محل نقاط پایانی پلتفرم؛ تقریباً بهترین چیزی که در یک چیدمان معمولیِ غیرهم‌مکان می‌توان داشت.
| مرحله | p50 | p95 | p99 |
|---|---|---|---|
| بسته‌شدن کندل ← دریافت رویداد بسته‌شدن کندل WS | 128 ms | 402 ms | 1,940 ms |
| تجزیه + به‌روزرسانی وضعیت ویژگی‌ها | 3 ms | 9 ms | 28 ms |
| تصمیم: ارزیابی مدل + بررسی‌های ریسک | 11 ms | 22 ms | 60 ms |
| ارسال سفارش ← تأیید صرافی | 47 ms | 180 ms | 1,100 ms |
| از ابتدا تا انتها (اندازه‌گیری‌شده، نه حاصل جمع) | 195 ms | 690 ms | 2,970 ms |
پیش از رسیدن به بخش جالب، دو نکته را در نظر بگیرید. اول اینکه میانه‌ها با هم جمع نمی‌شوند: 128 + 3 + 11 + 47 = 189، در حالی که میانهٔ اندازه‌گیری‌شدهٔ کل مسیر 195 است. صدک‌ها جمع‌پذیر نیستند؛ اگر برآورد تأخیرتان را با جمع‌کردن p99 هر مرحله بسازید، به 3,128 ms می‌رسید، در حالی که p99 واقعی 2,970 است. اینجا اختلاف قابل‌قبول است، اما وقتی مراحل در جهت مخالف هم‌بسته باشند، نتیجه به‌شدت غلط می‌شود. کل مسیر را اندازه بگیرید.
دوم، به ردیف بالایی نگاه کنید. دوسوم بودجهٔ میانه صرف انتظار برای اعلام بسته‌شدن کندل از سوی صرافی می‌شود. نه شبکه، نه کد شما، نه مسیریابی سفارش. پلتفرم معاملات را در یک کندل تجمیع می‌کند، پایان دقیقه را تشخیص می‌دهد و پیام را می‌فرستد. پیش از این پیام صفی وجود دارد و آن صف با همهٔ مشترکان دیگر آن جریان مشترک است.
عدد 840
هر یک از آن 1,418 سفارش را بر اساس نوسان تحقق‌یافتهٔ دقیقه‌ای که سیگنال را ایجاد کرده دسته‌بندی کنید؛ آن‌وقت توزیع از هم باز می‌شود.
| بازهٔ نوسان کندل سیگنال | تعداد سفارش‌ها | p50 از ابتدا تا انتها | p99 از ابتدا تا انتها |
|---|---|---|---|
| چارک پایینی | 201 | 141 ms | 488 ms |
| دو چارک میانی | 796 | 183 ms | 1,210 ms |
| چارک بالایی | 407 | 312 ms | 2,880 ms |
| 1٪ بالای همهٔ دقیقه‌ها | 14 | 840 ms | 4,100 ms |
عملکرد همهٔ مراحل هم‌زمان افت می‌کند و همین باعث انباشته‌شدن تأخیر می‌شود. صف تجمیع و پخش پلتفرم تحت‌تأثیر بار موتور تطبیق است؛ بنابراین دقیقه‌ای با 11,000 معامله دیرتر از دقیقه‌ای با 600 معامله ارسال می‌شود. فرایند خودتان هم در همان بازه به‌روزرسانی‌های عمق و چاپ معاملات بیشتری پردازش می‌کند، پس به‌روزرسانی ویژگی‌ها که معمولاً 3 ms طول می‌کشد، 28 ms زمان می‌برد. مسیر سفارش REST با هراس همهٔ دیگران رقابت می‌کند و گاهی با خطای 503 و تلاش مجدد روبه‌رو می‌شوید که به‌تنهایی یک ثانیه هزینه دارد. ضریب هم‌بستگی تعداد معاملات کندل سیگنال با تأخیر کل مسیر در نمونهٔ ما 0.41 بود. خیلی بزرگ نیست؛ اما برای خراب‌کردن یک مقدار ثابت کافی است.
استراتژی‌هایی هم که از غربال اولیه جان سالم به در می‌برند، عمدتاً شکست‌ها، بازگشت‌ها، واگرایی‌ها و آبشارهای لیکوییدشدن را معامله می‌کنند. این استراتژی‌ها دقیقاً در همان بازه‌ای فعال می‌شوند که تأخیر بدترین است. سیگنال مومنتومی که فقط وقتی حرکت دقیقه به 40 bps می‌رسد فعال می‌شود، از نظر ساختاری طوری طراحی شده که همیشه کندترین نسخهٔ سامانهٔ شما به آن پاسخ دهد.
یک‌بار یک روز کامل را صرف بررسی یک نقطهٔ پرت 3.6 ثانیه‌ای کردیم که تقریباً هر شب در همان زمان رخ می‌داد. مقصر logrotate بود: فایلی 2 GB را با روش کپی و خالی‌کردن روی همان حجم EBS که فرایند در آن می‌نوشت، مدیریت می‌کرد و حلقهٔ رویداد را از کار می‌انداخت. بازار بی‌تقصیر بود. اول اندازه‌گیری کنید و بعد بازار خرد را مقصر بدانید.
این تأخیر چه بلایی سر اجرای سفارش می‌آورد
تا وقتی منتظرید، قیمت حرکت می‌کند. در یک دقیقهٔ تصادفی، میانگین حرکت نامطلوب طی میانهٔ 195 ms ما حدود 1.1 bps در خلاف جهت سیگنال بود. در دقیقه‌های چارک بالایی، با 312 ms، به 5.8 bps می‌رسید. در دقیقه‌های 1٪ بالایی، با 840 ms، پیش از آنکه سفارش حتی به دفتر سفارش برسد، حدود 14 bps حرکت نامطلوب رخ می‌داد.
در قراردادهای دائمی BTC، اسپرد تقریباً نقشی در این ماجرا ندارد: یک تیک در قیمت 84,000 برابر 0.012 bps است؛ پس هزینه از حرکت نامطلوب می‌آید، نه عبور از اسپرد. همین استراتژی را به یک قرارداد دائمی با ارزش بازار متوسط منتقل کنید تا عامل دوم هم وارد شود: اسپرد بهترین قیمت خرید و فروش در نمونهٔ ما از 1.4 bps در دقیقه‌های آرام به 6.2 bps در چارک بالایی رسید و عمق همان قیمت بیش از نصف کاهش یافت. هم هزینهٔ حرکت نامطلوب را می‌پردازید، هم اسپرد گسترده‌تر را و هم عمق کمتر را؛ همه با هم، چون علت مشترکی دارند.
وقتی همان 31 روز را با تأخیر شرطی برای هر کندل، به‌جای 200 ms ثابت، دوباره شبیه‌سازی کردیم، میانگین قیمت ورود بک‌تست 3.1 bps بدتر شد؛ اثری که تقریباً به‌طور کامل در 9٪ معاملات متمرکز بود. اختلاف قیمت ورود بک‌تست با معامله‌گری کاغذی از 4.2 bps به 0.9 bps کاهش یافت. Sharpe درون‌نمونه‌ای آن استراتژی از 1.7 به 1.1 رسید؛ عدد صادقانه‌ای که از ابتدا هم همین بود.
پس در عمل چه چیزی را در پیکربندی می‌گذارید؟
یک مقدار ثابت نیست. کاری که حالا انجام می‌دهیم:
- نمونه‌برداری کنید، مقدار تعیین نکنید. تأخیر هر سفارش شبیه‌سازی‌شده را از یک توزیع تجربی بکشید که به فعالیت همان کندل وابسته باشد؛ تعداد معاملات و بازدهٔ مطلق کافی‌اند و هر دو در یک کندل استاندارد موجودند. برای هر پلتفرم و هر نوع سفارش یک‌بار برازش کنید و ماهانه دوباره برازش را انجام دهید.
- دُم توزیع را حفظ کنید. توزیع لگ‌نرمال را برازش نکنید و کار را تمام‌شده ندانید؛ p99 در طوفان‌های تلاش مجدد و مکث‌های GC پنهان است که هیچ توزیع همواری بازتولیدشان نمی‌کند. ما از چندک‌های تجربی استفاده می‌کنیم و بالاتر از p95 دُم را بازنمونه‌گیری می‌کنیم.
- تأخیر شامل لغو سفارش هم می‌شود. جایگزینی حد ضرر یا لغو سفارش پوشش ریسک هم همین تأخیر را دارد و در بازارهای پرشتاب، لغو سفارش شما با اجرای سفارش مسابقه می‌دهد. اگر شبیه‌سازتان سفارش را بی‌درنگ لغو می‌کند، مدل ریسکتان خیالی است.
- محافظ تازگی داده اضافه کنید و آن را شبیه‌سازی کنید. سامانهٔ ما هر سیگنالی را که هنگام رسیدن بیش از 1.5 ثانیه از عمر کندلش گذشته باشد حذف می‌کند. این رفتار واقعی هزینهٔ واقعی دارد: بی‌سروصدا معاملات را حذف می‌کند و بک‌تست هم باید همان معاملات را حذف کند.
- با داده‌های کاغذی دوباره تنظیم کنید. معامله‌گری کاغذی جایی است که به حقیقت مبنا می‌رسید. چهار مُهر زمانی هر گام را برای هر سفارش ثبت کنید و هر هفته توزیع‌ها را با فرض‌های شبیه‌ساز مقایسه کنید.
همین مشکل در بازارهای دیگر هم هست. سهام آمریکا: نوار معاملات تجمیع‌شده، علاوه بر کارگزار شما، تأخیر تجمیع خودش را اضافه می‌کند و به همان دلیل ساختاری، زیر فشار نرخ پیام گسترده‌تر می‌شود. بازارهای پیش‌بینی: در بیشتر پلتفرم‌ها ثبت سفارش فقط از طریق REST انجام می‌شود و میانه‌هایی کمتر از 100 ms اندازه گرفته‌ایم که هنگام رویداد تعیین نتیجه، با ورود هم‌زمان همه، به چند ثانیه می‌رسند. اختیار معاملهٔ کریپتو: ممکن است قیمت‌گذاری شما بر پایهٔ مظنه‌ای باشد که دقیقاً در همان دقیقه‌ای که دارایی پایه حرکت کرده، دو ثانیه از آن گذشته است.
صورت کلی این اشتباه آن است که پارامتر اجرا را یک مقدار ثابت و مستقل فرض کنیم، در حالی که تابع همان متغیر حالتی است که سیگنال شما را می‌راند. کارمزدها رفتار ثابتی دارند؛ نرخ تأمین مالی هم همین‌طور؛ اما تأخیر چنین نیست. اگر قرار است از همهٔ این حرف‌ها یک عدد در ذهن نگه دارید، نسبت را به خاطر بسپارید: p99 ما پانزده برابر میانهٔ ماست و سیگنال‌هایمان به‌طور نامتناسب نزدیک انتهای p99 می‌رسند.
چهار گام را ابزارگذاری کنید. یک بعدازظهر وقت می‌گیرد و دربارهٔ استراتژی‌تان بیشتر از یک هفته جست‌وجوی پارامتر به شما می‌گوید.
← همهٔ مطالب
