請問IB報價ES與YM在人工盤時段21:30~04:15一天大概有多少個Ticks
請問有人知道如果使用IB報價ES與YM在人工盤時段(21:30~04:15)一天大概有多少個Ticks嗎?
謝謝
本帖最後由 wldtw2008 於 16-7-12 16:00 編輯
IB的TICK跳動的方式其實很特別。
1. 當此次的(成交價、單量 ) 與上一次的(成交量、單量) 相同時，IB通知總量改變
2. 當此次的(成交價) 與上一次的(成交價)相同時，IB通知單量改變
3. 當此次的成交價與上一次的成交價不同時， IB通知價格改變
所以IB根本沒有所謂Tick，而是把所有的報價視為靜態，當某Item有異動時，送出該Item的新數值的方式來提供報價。
可以把他想成是一個報價白板網格，他只通知你網格中第幾行第幾列的數字有變動，你就去把那個網格內容擦掉更新。至於這次的通知是不是Tick那就不是他的事情了，要收資料的人自己去算了。
而IB似乎也有黏Tick的行為，或也有不接露黑池交易的行為。所以IB的報價都跟其他行情報價商的資料不太一樣。量不太準確的，但價還勉強可以參考。 本帖最後由 萬年船 於 16-7-12 17:14 編輯
wldtw2008 發表於 16-7-12 15:55
IB的TICK跳動的方式其實很特別。
1. 當此次的(成交價、單量 ) 與上一次的(成交量、單量) 相同時，IB通知總 ...
怎麼聽起來像是元大的YesWin越是贏DDE的傳輸方式
（元大YesWin DDE也是僅欄位異動通知
而元大EasyWin DDE則是有新Tick時，全部欄位都送一次，算是tick級了）
所以IB也是用DDE來傳輸資料到MC的嗎?
請問你有IB接進來的ES歷史資料嗎?
如果有，可否方便開一下Quote Manager
看看人工盤時段(台灣時區21:30~04:15；交易所時區08:30~15:15)
QuoteManager內大概有多少Tick
（在網路上找到些零碎資料，推估人工盤時段大約會有40萬到50萬的即時ticks）
我預計把既有策略分散到ES商品去
但有點擔心MultiCharts使用多數列時，累積這麼大量的即時Ticks後，效能會挺不住
想模擬測試一下，到時測完結果也分享給大家
（還沒寫那個模擬報價sQuote前，不會擔心MC，但寫完測過後，真的很擔心MC的承受力）
這年頭，買個數據源，還要擔心快市延遲，買個交易平台，還要擔心平台的承受力，當個明白的消費者還真辛苦
{:4_186:}
本帖最後由 wldtw2008 於 16-7-12 18:52 編輯
我在我自己的工具IBSim，走IB接口送入MC測過，1秒平均打入6000筆模擬tick(含BidAsk)資料(分散給50隻商品)，持續灌入一小時以上QM/MC不會當。而瞬間極速每秒超過9000個tick，還撐得住。
也就是一個小時QM總共收了2千萬筆資料，還扛的住。
但是MC那邊畫上去有沒有LAG我就不知道了，我沒有像您那樣的工具可以衡量。
有興趣的話，我可以提供我的工具，讓您測MC極限。 但坦白說我很擔心瓶頸是在我的工具上XD，畢竟當初的開發沒有預期到是這樣的用法。
我覺得MC/QM 的確需要更嚴謹的對待與測試，甚至有些要挽起袖子自己來探才知道有多深，但輸贏的關鍵也就是在這裡了。
至於IB收下來的ES的tick數，我明天來看一下再來報告。但我覺得不會很大，一則是我覺得IB有併TICK的行為，二則從他服務全世界這麼多客戶就知道，他如果不加工一下，怎麼扛的住那樣的流量?
抱歉我忘了說，我上面說的都是透過IB API用socket 方式接報價，而非用IBTWS 接DDE的。 本帖最後由 萬年船 於 16-7-12 21:57 編輯
我那個模擬報價sQuote也可指定每秒送給MC的模擬筆數，只不過是透過DDE
（我有試過，DDE只更新異動欄位方式（如元大YesWin），確實很容易在MC出現掉Tick
但如果是有新Tick，全部欄位都更新一次（如元大EasyWin），則MC端不容易掉Tick）
其實我的要求也不高，只要MultiCharts能應付全世界交易量最大的商品ES的即時ticks量
MultiChart並沒那麼糟糕，一般功能的效能都還OK
但如果使用到【多數列】且勾選【即時與歷史數列資料吻合】
那即時Tick累積到一個程度後，一出現快市，很容易CPU就會滿載，因而導致延遲
這種延遲不是以毫秒來算的，至少是數以秒計，或甚至數以分計
但只要取消勾選【即時與歷史數列資料吻合】，Tick累積的再多，經歷最大的快市CPU還是不會滿載
但取消勾選【即時與歷史數列資料吻合】實在沒意義，回測跟實際下單容易不一樣
很不幸的，我的策略使用到【多數列】且勾選【即時與歷史數列資料吻合】，要接軌ES就要小心了
就算暫時透過IB接軌ES成功後，最終還是得切換到eSignal，問題還是在
我可能還是得親自跟原廠反應一下此問題
（但尷尬的是，我是向台灣代理商買MC的，怕到時候原廠會有抵抗的情緒
但又指望不上K廠商能處理，該廠商連自家的開盤報價延遲與快市報價延遲都搞不定了）
哪有交易平台即時Tick累積到一個程度後，一出現快市CPU就容易出現滿載的，有點誇張
我剛看了一下，我這裡透過IB API收到的報價數量(僅供參考)
台灣時間7/11一整天，25648 ticks
台灣時間7/12一整天，37378 ticks wldtw2008 發表於 16-7-13 12:46
我剛看了一下，我這裡透過IB API收到的報價數量(僅供參考)
台灣時間7/11一整天，25648 ticks
台灣時間7/12 ...
W大，感謝您提供這項寶貴的資訊！
經過IB減量後的ES Tick筆數，竟然比台指還少（4、5萬筆）
這樣的Tick量，縱使MC用【多數列】且勾選【即時與歷史數列資料吻合】肯定也不會有問題的
在網路上找到些零碎資料
推估在人工盤時段，真實tick-by-tick的ES大約會有40萬到50萬筆（eSignal）
我還是先以40~50萬筆為模擬條件進行幾次合理的壓力測試
等這兩天測完，再上來分享於此文
IB提供的不是真實tick，所以如果需要 tick-based chart，那可以直接跳過了。
如果可以自己接api的話，可以接五秒線，資料會即時從historical data server stream過來，
可以拿來劃分線，不會有直接用 market data 價格高低點或成交量誤差的問題。
本帖最後由 TrendRover 於 16-7-13 13:57 編輯
CQGEPU16 --------
7/12 00:00 ----------------------------------------23:59:59498357
Rithmic esu6 --------the same period : 498444
=======================================================
目前我最相信 Rithmic 因為他最多!! 還有 AMP 的CQG 下單會 lag一下 超可怕的.
本帖最後由 萬年船 於 16-7-13 14:59 編輯
感謝各位大大所提供的寶貴資訊！
果然如我所推估的40~50萬筆ticks
就以40~50萬筆為模擬條件，對MultiCharts進行幾次合理的壓力測試
但因為不知快市究竟能快到什麼程度
姑且先把快市定義為每秒300筆ticks，每次快市持續10秒，不中斷
（註：台指快市最快大約就每秒350筆）
本帖最後由 萬年船 於 16-7-14 16:59 編輯
模擬測試使用：MonitorQuote_v2.0.2 (sQuote)
測試條件如下
1.交易主機硬體：E3-1231v3四核心八執行緒超頻3.8G、16G RAM
2.MultiCharts版本： 9.0 x86
3.時間長度：6.75小時（美國人工盤長度）
4.每個商品依機率在6.75小時內大約會出現24次快市
每次快市連續10秒不中斷，快市時每秒爆量300筆Ticks
5.一次全程累計Tick數約40萬筆
因為不知道ES快市究竟有多快，所以本測試以保守每秒300筆Ticks充當ES的快市
但其實台指快市每秒最高就可到300多筆了
很可能ES快市時，每秒會遠高於300筆，所以實際延遲應會比本模擬來的糟
sQuote參數如下圖所示
首先測試同時段只執行一個ES策略（策略有用到【多數列】且勾選【即時與歷史數列資料吻合】）
延遲如下圖所示
接著測試同時段共執行八個ES策略（策略有用到【多數列】且勾選【即時與歷史數列資料吻合】）
延遲如下圖所示
放大檢視最後一次10秒快市時的延遲，如下圖所示
第一次快市時，CPU核心使用率（紅框標示區），如下圖所示
最後一次快市時，CPU核心使用率（紅框標示區），如下圖所示
本帖最後由 TrendRover 於 16-7-15 11:08 編輯
我看到最快的約:
9.1ms跳進 5筆---每筆約1.8ms !07/12 08:30附近-----CQG
好久沒回來逛逛---W 大你好~~
萬大您程式功力那高
就自己寫程式下單就好
反正都是接報價 免得MC造成你困擾
我自己接群益API 盤後收報價(只收台指期)
同時開四個CHART 顯示指標和均線約15個
一秒就收完70000個TICK
我相信ES更快
如要必免超快市 應該要不能超過0.1秒的DELAY
不然價格一定差很多
您參考
本帖最後由 萬年船 於 16-7-15 14:27 編輯
To T大,
請問你的Rithmic數據源是哪來的呢？AMP開戶附的嗎？還是另外購買的像eSignal一樣？
如有空且在非交易時間，可開MultiCharts圖表，一眼就可很清楚的找出
1.快市最快程度
2.普遍快市程度（一次連續多秒大量tick的眾數，即出現最多的高度）
如下圖所示（資料區間看是要用10天或30天）
To J大,
2008年那個時候開始，我就是全部DIY
（接下單、接報價、回測引擎、最佳化引擎、自動交易引擎）
但想到之後如果要交易其他交易所的商品，還得再來一遍
APIs異動，還得持續維護，想到就累
於是我開竅了，我是來交易賺錢的，不是來當黑手的
所以2014年，我就金盆洗手，改用MultiCharts平台了
真的不想再回去當黑手了{:4_186:}
現在只剩幾件事，我仍必須當黑手
1.檢測付費數據源是否有快市延遲，有則客訴或換數據源
2.檢測交易平台是否有些功能或語法有瓶頸，盡量避開且請原廠修復
目前我看到MC有淺在效能問題的，其實也只有當以下三個條件同時成立時，才容易會有效能瓶頸
1.即時Tick累積到非常大時（數萬筆，所以台指是安全的）
2.使用多數列
3.勾選realtime history matching
其他的情況，大概開再多的圖表視窗，再大的快市，MC也都不容易產生效能瓶頸
另外，其實我幾乎都用停止單，而ES在交易所直接支援停止單，小延遲應該還好
但台指沒支援停止單，快市時延遲數秒，就會很慘
頁:
[1]
2