כמה שיהוי כדאי להוסיף לבדיקת עבר? מדדנו כל אלפית שנייה אצלנו

ארבעה מספרים, כולם נמדדו במערכת המסחר המדומה שלנו, באסטרטגיה אחת, עם אותות לחוזה תמידי BTCUSDT בגרף 1-minute, במשך 31 ימים ועם 1,418 פקודות. הזמן החציוני מסגירת הנר ועד לאישור הפקודה בבורסה: 195 ms. האחוזון ה-99: 2,970 ms. החציון בדקה עם התנודתיות הממומשת הגבוהה ביותר ב-1%: 840 ms. וקבוע השיהוי שהוגדר בתצורת בדיקת העבר במשך רוב השנה שקדמה לכך: 0.

שלושה מהמספרים האלה משעממים. כולם יודעים שהאפס שגוי, כולם מחליפים אותו בסוף במשהו, והמשהו הזה הוא כמעט תמיד קבוע שמישהו בחר לפי תחושת בטן. 100 ms, 250 ms, "נהיה שמרנים, 500." המספר שבאמת חשוב הוא 840, כי הוא אומר שהשיהוי שלכם תלוי במצב השוק, ומצבי השוק שבהם הוא מזנק הם אותם מצבים שבהם האות שלכם חושב שמצא משהו.

לאן הולכות 195 אלפיות השנייה

הנה התקציב המלא, שנמדד בכל שלב באמצעות חותמות זמן משעון מונוטוני בכל מעבר. השרת הוא מופע AWS באזור ap-northeast-1, באותו אזור כמו נקודות הקצה של הזירה, וזה קרוב לאופטימלי ככל שמערכת קמעונאית שאינה ממוקמת יחד עם הבורסה יכולה להגיע.

שני דברים שכדאי לשים לב אליהם לפני שניגשים לחלק המעניין. ראשית, החציונים לא מסתכמים: 128 + 3 + 11 + 47 = 189, בעוד שחציון הזמן שנמדד מקצה לקצה הוא 195. אחוזונים אינם מצטברים, ואם תחשבו את אומדן השיהוי שלכם על ידי חיבור ערכי p99 של כל שלב, תקבלו 3,128 ms, בעוד שה-p99 האמיתי הוא 2,970. כאן זה קרוב מספיק, אבל כשהשלבים מתואמים בכיוון ההפוך הטעות יכולה להיות עצומה. מדדו את המסלול כולו.

שנית, הסתכלו בשורה העליונה. שני שלישים מתקציב החציון מתבזבזים בהמתנה לכך שהבורסה תודיע לכם שהנר נסגר. לא הרשת, לא הקוד שלכם ולא ניתוב הפקודות. הזירה מאגדת עסקאות לנר kline, מחליטה שהדקה הסתיימה ודוחפת את העדכון. יש תור לפני השליחה הזאת, והוא משותף לכל המנויים האחרים באותו ערוץ.

ה-840

חלקו את כל 1,418 הפקודות לפי התנודתיות הממומשת בדקה שהפיקה את האות, וההתפלגות מתפצלת.

הביצועים של כל השלבים מידרדרים יחד, ולכן ההשפעה מצטברת. עומס על מנוע ההתאמה מזין את תור האיגוד והשידור של הזירה, כך שדקה עם 11,000 עסקאות נשלחת מאוחר יותר מדקה עם 600. באותו חלון התהליך שלכם מטפל ביותר עדכוני עומק וביותר הדפסות עסקאות, ולכן עדכון הפיצ'רים שבדרך כלל נמשך 3 ms נמשך 28. נתיב הפקודות דרך 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, כך שהנזק נובע מתנועה לרעתכם ולא מעלות החצייה. העבירו את אותה אסטרטגיה לחוזה תמידי של מטבע בעל שווי שוק בינוני, והרכיב השני מתעורר — מרווח ה-top of book במדגם שלנו גדל מ-1.4 bps בדקות רגועות ל-6.2 bps ברבעון העליון, והעומק במחיר הטוב ביותר הצטמצם ביותר ממחצית. אתם משלמים על התנועה לרעתכם, על המרווח הרחב יותר ועל העומק הדל יותר, הכול בבת אחת, מאותה סיבה.

כששחזרנו את אותם 31 ימים עם שיהוי מותנה בכל נר במקום 200 ms אחידים, מחיר הכניסה הממוצע בבדיקת העבר היה גרוע ב-3.1 bps, כמעט כולו מרוכז ב-9% מהעסקאות. הפער בין מחיר הכניסה בבדיקת העבר למחיר במסחר המדומה ירד מ-4.2 bps ל-0.9 bps. Sharpe בתוך המדגם באסטרטגיה הזאת ירד מ-1.7 ל-1.1, וזה המספר האמיתי — והוא תמיד היה כזה.

אז מה באמת מגדירים בתצורה

לא ערך יחיד. כך אנחנו עובדים עכשיו:

1. דוגמים במקום לקבוע ערך. דגמו את השיהוי לכל פקודה מדומה מתוך התפלגות אמפירית שמותנית בפעילות של אותו נר — מספר העסקאות והתשואה המוחלטת מספיקים, ושניהם כבר מופיעים ב-kline סטנדרטי. התאימו פעם אחת לכל זירה ולכל סוג פקודה, ועדכנו את ההתאמה מדי חודש.
2. שמרו על הזנב. אל תתאימו התפלגות לוגנורמלית ותחשבו שסיימתם; ה-p99 נובע מסופות של ניסיונות חוזרים ומהשהיות GC ששום התפלגות חלקה לא משחזרת. אנחנו משתמשים באחוזונים אמפיריים, עם דגימה מחדש של הזנב שמעל p95.
3. השיהוי חל גם על ביטולים. החלפת פקודת עצירה או ביטול פקודת גידור כפופים לאותו עיכוב, ובשווקים מהירים הפקודה שלכם לבטל מתחרה במילוי. אם הסימולטור שלכם מבטל מיד, מודל הסיכון שלכם בדיוני.
4. הוסיפו מגבלת התיישנות ודמו אותה. אנחנו משליכים כל אות שהנר שלו ישן מ-1.5 שניות כשהוא מגיע. זו התנהגות אמיתית עם עלות אמיתית — היא מסירה עסקאות בלי להתריע, והיא חייבת להסיר את אותן עסקאות גם בבדיקת העבר.
5. כיילו מחדש מול מסחר מדומה. מסחר מדומה הוא המקום שבו מקבלים את נתוני האמת. תעדו את חותמות הזמן של ארבעת המעברים בכל פקודה והשוו מדי שבוע את ההתפלגויות להנחות הסימולטור.

הטעות הכללית היא להתייחס לפרמטר ביצוע כאל קבוע בלתי תלוי, אף שהוא פונקציה של אותו משתנה מצב שמניע את האות שלכם. עמלות מתנהגות יפה; גם מימון; שיהוי לא. אם תיקחו מספר אחד מכל זה, קחו את היחס: ה-p99 שלנו גבוה פי חמישה עשר מהחציון, והאות שלנו מגיע באופן לא פרופורציונלי סמוך לקצה ה-p99.

הוסיפו מדידה לארבעת המעברים. זו עבודה של אחר צהריים והיא תלמד אתכם יותר על האסטרטגיה שלכם מעוד שבוע של חיפוש פרמטרים.