Bốn con số, đều được đo từ chính hệ thống giao dịch mô phỏng của chúng tôi, trên một chiến lược, tín hiệu hợp đồng vĩnh cửu BTCUSDT khung 1 phút, trong 31 ngày với 1,418 lệnh. Thời gian trung vị từ lúc nến đóng đến khi sàn xác nhận lệnh: 195 ms. Phân vị thứ 99: 2,970 ms. Trung vị trong 1% số phút có biến động thực tế cao nhất: 840 ms. Còn hằng số độ trễ trong cấu hình backtest suốt phần lớn năm trước đó: 0.
Ba trong số đó chẳng có gì đáng ngạc nhiên. Ai cũng biết con số 0 là sai, rồi sớm muộn cũng thay nó bằng một giá trị nào đó; và giá trị ấy hầu như luôn là một hằng số được chọn theo cảm tính. 100 ms, 250 ms, “cứ thận trọng, lấy 500”. Con số thực sự quan trọng là 840, vì nó cho thấy độ trễ phụ thuộc vào trạng thái thị trường, và những trạng thái khiến độ trễ tăng vọt cũng chính là lúc tín hiệu của bạn cho rằng nó đã phát hiện ra cơ hội.
195 mili giây đi đâu mất
Đây là bảng phân bổ đầy đủ, được đo theo từng giai đoạn bằng dấu thời gian từ đồng hồ đơn điệu tại mỗi điểm chuyển tiếp. Máy chủ là một phiên bản AWS ở ap-northeast-1, cùng khu vực với các điểm cuối của sàn; gần như tối ưu nhất có thể đối với một hệ thống kiểu nhà đầu tư cá nhân không đặt máy chủ cùng địa điểm.
| Giai đoạn | p50 | p95 | p99 |
|---|---|---|---|
| Nến đóng → nhận sự kiện WS kline-closed | 128 ms | 402 ms | 1,940 ms |
| Phân tích cú pháp + cập nhật trạng thái đặc trưng | 3 ms | 9 ms | 28 ms |
| Ra quyết định: chạy mô hình + kiểm tra rủi ro | 11 ms | 22 ms | 60 ms |
| Gửi lệnh → sàn xác nhận | 47 ms | 180 ms | 1,100 ms |
| Toàn bộ quy trình (đo thực tế, không cộng các giai đoạn) | 195 ms | 690 ms | 2,970 ms |
Có 2 điều cần lưu ý trước khi đến phần đáng chú ý. Thứ nhất, các giá trị trung vị không cộng lại thành nhau: 128 + 3 + 11 + 47 = 189, còn trung vị đo được cho toàn bộ quy trình là 195. Các phân vị không có tính cộng gộp; nếu ước tính độ trễ bằng cách cộng p99 của từng giai đoạn, bạn sẽ ra 3,128 ms trong khi p99 thực tế là 2,970. Ở đây sai số không lớn, nhưng có thể sai lệch nghiêm trọng nếu các giai đoạn tương quan theo chiều ngược lại. Hãy đo toàn bộ quy trình.
Thứ hai, hãy nhìn hàng đầu tiên. Hai phần ba độ trễ trung vị là thời gian chờ sàn báo cho bạn biết nến đã đóng. Không phải mạng, không phải mã của bạn, cũng không phải định tuyến lệnh. Sàn tổng hợp các giao dịch thành nến, xác định phút đã kết thúc rồi gửi dữ liệu đi. Tín hiệu gửi đó phải chờ trong một hàng đợi dùng chung với mọi thuê bao khác trên luồng.
Con số 840
Chia 1,418 lệnh theo biến động thực tế của phút tạo ra tín hiệu, bạn sẽ thấy phân phối thay đổi rõ rệt.
| Nhóm biến động của nến phát tín hiệu | Số lệnh | p50 toàn quy trình | p99 toàn quy trình |
|---|---|---|---|
| Tứ phân vị thấp nhất | 201 | 141 ms | 488 ms |
| Hai tứ phân vị giữa | 796 | 183 ms | 1,210 ms |
| Tứ phân vị cao nhất | 407 | 312 ms | 2,880 ms |
| 1% số phút có biến động cao nhất | 14 | 840 ms | 4,100 ms |
Mọi giai đoạn đều chậm lại cùng lúc, khiến tác động cộng dồn. Tải của bộ máy khớp lệnh làm tăng tải lên hàng đợi tổng hợp và phát dữ liệu của sàn, nên phút có 11,000 giao dịch sẽ được gửi đi muộn hơn phút có 600 giao dịch. Trong cùng khoảng thời gian, tiến trình của bạn cũng phải xử lý nhiều cập nhật độ sâu và nhiều giao dịch hơn, nên bước cập nhật đặc trưng vốn mất 3 ms có thể mất 28 ms. Đường truyền lệnh REST phải cạnh tranh với lệnh khẩn cấp của mọi người khác; đôi khi bạn gặp lỗi 503 rồi phải thử lại, riêng việc đó đã tốn thêm trọn một giây. Hệ số tương quan giữa số giao dịch trong nến phát tín hiệu và độ trễ toàn quy trình trong mẫu của chúng tôi là 0.41. Không quá lớn, nhưng đủ để khiến một hằng số trở nên vô dụng.
Những chiến lược vượt qua vòng sàng lọc đầu tiên phần lớn là chiến lược giao dịch phá vỡ, đảo chiều, lệch giá và thanh lý dây chuyền. Chúng kích hoạt đúng trong nhóm mà độ trễ tệ nhất. Tín hiệu động lượng chỉ bật khi giá biến động 40 bps trong một phút về cơ bản đã tự sắp đặt để luôn được xử lý bởi phiên bản chậm nhất trong hệ thống của bạn.
Có lần chúng tôi mất cả ngày truy tìm một ngoại lệ 3.6 giây xuất hiện gần như cùng một giờ mỗi đêm. Thủ phạm là logrotate: sao chép rồi cắt một tệp 2 GB trên cùng ổ EBS mà tiến trình đang ghi, khiến event loop bị đình trệ. Thị trường vô can. Hãy đo trước rồi mới đổ lỗi cho vi cấu trúc thị trường.
Điều đó ảnh hưởng đến khớp lệnh ra sao
Giá trượt trong lúc bạn chờ. Trong một phút ngẫu nhiên, mức biến động bất lợi trung bình trong 195 ms trung vị của chúng tôi vào khoảng 1.1 bps so với hướng tín hiệu. Với các phút thuộc tứ phân vị cao nhất, ở mức 312 ms, con số là 5.8 bps. Còn trong 1% số phút có biến động cao nhất, ở mức 840 ms, giá đã trượt bất lợi khoảng 14 bps trước cả khi lệnh đến sổ lệnh.
Với hợp đồng BTC vĩnh cửu, chênh lệch giá hầu như không góp phần vào vấn đề này: 1 tick trên mức giá 84,000 tương đương 0.012 bps, nên thiệt hại đến từ trượt giá bất lợi chứ không phải chi phí khớp qua spread. Chuyển cùng chiến lược sang hợp đồng vĩnh cửu vốn hóa trung bình, yếu tố thứ hai bắt đầu đáng kể: spread đầu sổ lệnh trong mẫu của chúng tôi tăng từ 1.4 bps ở những phút yên ả lên 6.2 bps trong tứ phân vị cao nhất, còn độ sâu tại mức giá đó giảm hơn một nửa. Bạn phải chịu trượt giá, spread rộng hơn và độ sâu kém hơn cùng lúc, tất cả đều do chung một nguyên nhân.
Khi chạy lại cùng 31 ngày với độ trễ có điều kiện theo từng nến thay vì cố định ở 200 ms, giá vào lệnh trung bình trong backtest xấu hơn 3.1 bps, gần như toàn bộ tập trung ở 9% số giao dịch. Chênh lệch giá vào lệnh giữa backtest và giao dịch mô phỏng giảm từ 4.2 bps xuống 0.9 bps. Sharpe trong mẫu của chiến lược giảm từ 1.7 xuống 1.1; đó mới là con số trung thực, và vốn dĩ từ đầu đã là như vậy.
Vậy nên đặt gì trong cấu hình
Đừng dùng một giá trị duy nhất. Hiện chúng tôi làm như sau:
- Lấy mẫu, đừng tự đặt. Lấy độ trễ cho mỗi lệnh mô phỏng từ phân phối thực nghiệm có điều kiện theo mức hoạt động của chính nến đó — chỉ cần số giao dịch và lợi suất tuyệt đối, cả hai đều có sẵn trong kline tiêu chuẩn. Khớp phân phối riêng cho từng sàn và loại lệnh, cập nhật hàng tháng.
- Giữ lại phần đuôi phân phối. Đừng khớp phân phối lognormal rồi cho là xong; p99 nằm trong các đợt thử lại liên tiếp và những lần GC tạm dừng mà không phân phối trơn nào mô phỏng được. Chúng tôi dùng các phân vị thực nghiệm, lấy mẫu lại phần đuôi phía trên p95.
- Lệnh hủy cũng chịu độ trễ. Lệnh thay thế stop hoặc hủy lệnh phòng hộ cũng chịu cùng độ trễ; trong thị trường biến động nhanh, lệnh hủy của bạn đang chạy đua với một lần khớp. Nếu trình mô phỏng hủy tức thì, mô hình rủi ro của bạn chỉ là hư cấu.
- Thêm cơ chế chặn tín hiệu cũ và mô phỏng cả cơ chế đó. Hệ thống của chúng tôi loại bỏ mọi tín hiệu có nến đã cũ hơn 1.5 giây khi nhận được. Đây là hành vi thực tế, có chi phí thực tế — nó âm thầm loại bỏ giao dịch, và backtest cũng phải loại bỏ chính những giao dịch đó.
- Hiệu chỉnh lại bằng dữ liệu giao dịch mô phỏng. Giao dịch mô phỏng là nơi bạn có được dữ liệu thực tế chuẩn xác. Ghi lại 4 dấu thời gian tại các điểm chuyển tiếp cho mọi lệnh, rồi hàng tuần so sánh các phân phối với giả định của trình mô phỏng.
Lớp tài sản khác, cùng một vấn đề. Cổ phiếu Mỹ: băng giá tổng hợp cộng thêm độ trễ tổng hợp bên cạnh độ trễ từ nhà môi giới, và độ trễ này tăng khi lưu lượng thông điệp chịu áp lực vì cùng nguyên nhân cấu trúc. Thị trường dự đoán: hầu hết sàn chỉ cho vào lệnh qua REST; chúng tôi đo được trung vị dưới 100 ms nhưng tăng lên vài giây khi có sự kiện phân xử và mọi người cùng lúc đổ vào. Quyền chọn tiền mã hóa: báo giá bạn dùng để định giá có thể đã cũ 2 giây đúng vào phút tài sản cơ sở biến động.
Sai lầm thường gặp là coi tham số khớp lệnh như một hằng số độc lập, trong khi nó phụ thuộc vào chính biến trạng thái đang chi phối tín hiệu. Phí có quy luật; funding có quy luật; độ trễ thì không. Nếu chỉ nhớ một con số từ bài này, hãy nhớ tỷ lệ: p99 của chúng tôi cao gấp 15 lần trung vị, còn tín hiệu của chúng tôi thường đến gần phía p99 hơn hẳn.
Hãy ghi nhận thời gian tại cả 4 điểm chuyển tiếp. Chỉ mất một buổi chiều, và kết quả sẽ cho bạn biết về chiến lược nhiều hơn cả một tuần tìm kiếm tham số.
← Tất cả bài viết
