高頻交易中是否需要實時操作系統？

01-15

在高頻交易中，對每筆下單的速度都有著速度的要求，那是否應該採用實時操作系統呢？這樣子可以避免非實時操作系統的不確定性而導致無法很快的相應行情。

Hft系統一般都盡量繞開os. 比如：把線程綁定到單獨的核上繞開調度器；使用object pool和預先分配繞開內存管理；使用kernel bypass避開os的協議棧；我的地盤我做主，實時os能提供的東東西，大家並不怎麼需要。你能在16個核上跑32個線程，同時保證合理的latency -- 可是你為毛要跑那麼多線程啊？

我沒有實際接觸過任何一種「實時操作系統」，以下看法可能有失偏頗，歡迎熟悉這方面的同學指正。

從維基頁面Real-time operating system上來看，實時操作系統主要做了以下幾個方面的工作：

專門的進程調度演算法。基本思想是說進程進入閑置狀態後，重新激活需要排隊。所以實時系統的調度演算法針對處理實時任務的進程做了優化，保證它們不被非實時任務搶先。
為了在多個實時任務之間共享數據和硬體，做一些特殊的處理。比如放權給應用程序使其可以越過操作系統去臨時禁止硬體中斷，保證實時任務在處理過程中不會受到任何干擾。
實時任務可能有一些處理是寫在中斷處理（Interrupt Handler）中以保證最大程度的獨佔硬體資源，這導致的問題是如果在這個過程里調用System Call而修改了內核中的一些狀態，會和非中斷的程序調用類似的System Call而產生的修改產生衝突。所以做了一些設計來解決這個問題，比如在更新內核狀態的時候禁止中斷。
內存分配上，針對內存碎片做了一些優化設計。

僅就這幾點而言，以我的個人理解，高頻交易沒有必要採用實時操作系統。這是因為，現代的通用操作系統和硬體都已經發展到非常成熟和複雜的程度。在多核架構下，完全可以做到分出幾個核給應用程序獨佔，愛怎麼用就怎麼用，操作系統不會跟你爭。中斷也可以自己控制（Balancing Hardware Interrupts）。至於內存分配，避免碎片是高水平的程序員可以自己操作的，對系統沒什麼依賴。

我的理解是，實時系統在一些嵌入式硬體上有應用價值。因為硬體資源非常有限，通用系統的很多設計不僅沒用反而會增加負擔，這種情況下採用專門的實時系統是有必要的。但是一個高頻交易系統本身在硬體設計上沒有任何限制，想用什麼就用什麼，硬體資源（CPU，內存等）非常豐富，甚至超出實際需要，這種情況下，只要對通用操作系統有正確和深入的理解，是完全可以實現實時處理的需求的。

實時操作系統，比如vxworks或qnx等，追求的是響應速度，比如一個高優先順序任務能在多長時間被執行，一個要停止的任務多快截止。其特殊技術一般是微內核等，面向的問題是多個任務進程級別的調度。高頻系統追求的是下單等的低延遲，是同一個服務內部的高速，調度是儘可能避免的，主要技術是cache friendly programming, user space network stack等

網路延遲是數百毫秒級別的，Win64的任務切換是微秒級別的，Linux稍快些。

首先，有功夫整操作系統還不如整整網路。譬如，現代的操作系統，不論是Windows還是Linux，其TCP/IP棧設計的首要原則是重載（尤其是Windows，自Windows 2000起採用了FreeBSD的TCP/IP棧），都是扛造第一速度第二。

因此換用速度第一原則的TCP/IP棧，或者調整TCP/IP棧的參數，都會取得立竿見影的效果，至少在你這一側的網路是為速度優化過了（別指望交易所優化，他們的伺服器優先原則是抗造）。

第二，演算法非常重要。譬如FIX協議的解析，華爾街最優秀的能做到單伺服器Java 1000萬指令/秒、C++ 6000萬指令/秒，我不清楚國內的平均水平，不過自測Java超過300萬指令/秒不難。

第三，優化進程/線程的同步。別讓訂單、策略啥的傻等。

和 @董可人一樣沒有上手操作過，但在選linux distribution的時候做過一些調研。

個人覺得實時系統的主要目的不是降低Average Latency，而是保證最壞的Latency在一定範圍內。

如果要做對於data stream有順序要求的操作（非常多的time series analysis），可以嘗試一下實時系統。

竊以為與實時系統相比，zero-copy或者kernal-bypass之類高大上的技術更值得研究。

和實時操作系統沒有關係。。。

接觸過多個實時操作系統，pSOS，VxWorks，RT Linux，uCOS，free RTOS…

實時操作系統最重要的一點是輸入到輸出的時間是可預期的。

火箭、衛星用的都是實時操作系統。

一個液晶電子鬧鐘也可能用了實時操作系統。

沒接觸過高頻交易系統，憑印象它不可能需要使用實時操作系統。

1. 基於網路的應用，大部分時間延遲來自於網路，即使本地使用了實時系統，時間仍然不可控，網路的延遲是多少還是多少；

2. 所有任務處理最終還是處器一條條指令執行，一般使用實時系統每個任務會少用成千上萬條指令，但這個速度的提高對於目前性能的計算機以及高頻交易這樣的應用可能毫無必要，因為每個任務處理可能節約了不到1ms時間。

3. 大部分實時系統又可以稱呼為嵌入式實時系統，用於嵌入式產品。

4. 如果在實時系統上開發高頻交易系統，出品公司可能要指定某一種計算機硬體。

5. 在大部分實時系統上開發一個含大量形界面的應用軟體，會令很多工程師吐血。

回答評論：

主要受代碼和數據存儲空間的限制，排除這個限制，就是複雜度和工作量的問題，理論上可以，但基本沒有人這樣做

不需要實時系統。

實時系統通常是對時間的精確度要求很高的時候才需要，或者是要求必須在規定的時間內做出有效響應。

主要應用在工業控制領域。

例如，飛機的飛控系統，必須在若干ms內完成一次閉環計算，火箭也是如此，否則就可能導致飛行姿態不穩定，影響飛行軌跡的控制精度。

而響應時間的限制也是如此，假如飛機在高速貼地飛行，超過幾毫秒的響應時間就可能墜毀。

對於所謂的高頻次交易處理，關心的不是實時性，而是並發數，多少會撐不住。但是在交易比較密集的時候按順序處理，稍微延遲幾十毫秒甚至幾秒鐘，並不是什麼大問題。

最近看了一些關於高頻的文章

其實有一個誤區就是高頻交易是幹嘛的

題主的這個問題中所需要的快速交易系統並不是真正的高頻交易系統

（高頻交易系統實際上主要的存在意義是作市，為場上所有交易提供對手盤，提供流動性，套取微小的點差，不是通過交易策略來賺錢的，系統要求非常高，動輒數億美元，不是個人和小公司所能承受的）

=======================================

對於普通快速交易的要求

個人覺得不需要rtos

實時只是精確，並不必然快。

硬實時的系統裡面規則貌似是到了規定時間哪怕沒有計算完成也要輸出估算結果，這種特性用不好會出問題的。

畢竟代碼要重新寫，收益不見得值得這麼搞。以及前面有人說的網速是延遲的大頭，本地哪怕是非實時的，延遲基本都是幾個ms以下的，你確定你一秒鐘之內需要完成兩百次交易么？

其實從我的實踐經驗看策略是第一的。

從行情獲得到指令發出一定是有延時的，如果期貨交易所提供足夠的交易行情那是可以隨求一下速度，但是一定是有延時的所以穩定和策略是第一的。

沒接觸過但是把大的計算量放在ASIC里之後在一般操作系統里下單速度應該能夠快了

1、同樣的軟體：速度在於操作和網路。

2、不同的軟體：速度在於軟體怎麼寫的和網路。

說白了，和實不實時無關，真用了實時的系統，一是難為寫軟體的，二是實時系統的軟體其實不適合做這種事，弊端多於利端。

都寫的好長。硬實時系統的一個簡單定義就是在任意時刻能否在給定時間t內對外部事件做出響應。t根據應用場景從ns到ms不等。比如戰鬥機或火星車。1ms已經跑出去半米了。 VxWorks在100mhz cpu上typical能做到20us。

linux不適合做rtos。和其他嵌入式os相比太臃腫了。

我理解交易系統屬於高吞吐系統而非實時系統，這兩種系統的設計是截然相反的。交易系統應該保證的是在並發high throughput場景下的效率最高。而不是頻繁被各種事件打斷。

肯定是要的，有系統自然方便得多。

實時操作系統VXWORK 一般用在武器操控系統大型工控系統內部拓撲簡單帶寬高延遲低可以顯著提升系統響應速度

我參與的不是金融高頻交易而是RTB的Exchange 在RTB中程序ns級別很容易做到再快就沒有顯著提升的價值了

實時分硬實時軟實時。軟實時系統是個概率問題，主流OS都可歸為這一類。硬實時系統要求任務執行時間有確定性的上限，用的也不多--有這種要求時，該不該用OS，甚至該不該丟掉處理器直接硬體實現，都值得商榷。高頻演算法交易沒可能有這種要求，通用OS足以勝任，折騰這些不如優化演算法、架構和網路。

這個問題我來回答吧，高頻操作，就是每秒鐘有很多 io和計算，根據目前的計算機技術水平來說做到實時很難，，，qq等軟體每秒有上億次的信息傳輸和計算，但是不是實時操作系統，也沒必要實時，只要計算速度和輸入輸出速度在一定的可接受範圍即可，就算是宇宙飛船火箭等也不是實時的，只是儘可能保證在多少毫秒完成請求即可。還有世界上不存在實時操作系統，你看到的實時操作系統都是指反應更快一點，，io能力更強一點。所以呢高頻交易一般情況都不一定要實時操作系統，而是通過改進吞吐量和計算io分離等措施提高響應速度。。。。。完畢