這邊提醒一下兩家報價的架構差異
TC會做併筆資料，也就是同一時間有兩筆相同的資料，它會合併成一筆才送出，所以資料量會小一些，凱衛的不會，交易所送來什麼，它就送出什麼
另外是凱衛現在的元件會在本地做組合分K，效率較差
這部份，新報價才會在伺服器上處理後才丟出來，開盤問題也是要等新報價主機後才會去解決，目前只有內測，還沒有開放外測
====================================================================================================== 客服一號老師您好:
聽起來好像要改併筆? 希望我看錯意思. 目前我有參考凱衛的一些量數據 (upticks downticks ticks)
如果要改併筆, 這些值是否能維持原來的意義? 或者至少能讓使用者選擇不要併筆?
如果貿然改成併筆, 恐怕我的程式會有問題, 凱衛應該不會硬改硬要客戶接受吧?
或者應該分成兩種商品, 原先的 TXF1 維持不動, 另外新增商品有併筆, 讓想用的跟不想用的各取所需?
我個人寧可都不改變, 也不要為了速度改變了upticks downticks 的算法.
(upticks downticks 是在本地端自己算的, 改版併筆表示每次的 ticks 量不同, upticks downticks 就不太可能會一樣)
感謝您
我也反對報價改為併筆
這不是進步，而是倒退的做法
沒記錯的話，國外付費的報價商都是tick by tick
若報價改為併筆這對歷史資料的品質會造成很大的影響
需要用到tick資料做交易的人影響也很大
凱衛若要改善報價速度應該從其它方面改善
而不是改為併筆這種報價品質倒退的做法
我個人對目前凱衛的報價速度是滿意的
對我而言報價資料的準確性比報價快幾ms來的重要
但每個人的需求不同
請凱衛也考量需要tick by tick報價的使用者
我上面寫的是 TC 用的是併筆法
並不是說 KWAY 要改用併筆法，KWAY新價主要改進的是server組K棒功能（減少本地端的loading），以後就不會有台灣K或國際K，只有一種K了
至於你說的快市延遲到好幾秒的問題
因為真實tick的問題，就會造成網路傳輸量的爆增
本地的處理量也會爆增，主要要看右下角有沒有紅色出現 x q/x s 的訊息
有的話，問題不在網路，而是本身的CPU來不及消化網路塞進來的資訊
圖表愈多本地處理量就會成倍的增加
併筆的好處就是它可以讓處理量減少，因此TC在快市時是有優勢的，這一點沒有錯
但我自已的STOP單比例並不高，所以我自已是覺得KWAY的報價還OK
滑價的情況並不高，在可接受的範圍內
我自已也是實單在交易的，所以並不是在幫KWAY說話
目前KWAY最大的問題在於開盤延遲那個問題，其他的，我覺得是還可以接受的，相對於其他報價而言
併筆或是改成主機先組好K棒再傳, 我想客戶都會有一個疑問, 數據部分跟以前的意義相同嗎?
如果相同又能改進反應速度, 客戶應該不會想反對, 雖然我仍是希望以試用的方式先看改了與原先是否有差再換
不過這可以先打住
以下是我自己的推想, 如果沒興趣請跳過
=======================================================
以前對量的計算是, 丟一次單量, 然後本地端去計算累積的 ticks, upticks, downticks 變成多少
如果核心(ticks upticks downticks 的累積與計算)不能改, 也就是一次 ticks 只能歸屬成 upticks or downticks or 都不是
那麼對非 IOG 圖表, 主機端只要在知道本地端圖表週期後, 在 K棒 結束時丟三個 ticks, 分別是給 upticks downticks 跟剩下的量, 任務就達成了.
(丟三次是舉例, 因為丟一次無法同時更新 upticks downticks 跟 成交量, 成交量 大於等於 upticks+downticks, 丟之前要預估公式運算成 "同樣結果" 才行, 漏丟 tick 要補丟這個問題應該不用擔心, 測試中會碰到)
但對 IOG
不管什麼方法計算出量 (主機端送 K棒中當時的累積量 或是 單量在客戶端計算)
一定是有一次 tick 就要送一次數字, 也就是沒有減少傳送次數
那...這樣應該一樣會 lag .... 吧... 不知道改成主機算量要怎麼改善 IOG 的 lag?
我不是凱衛的工程師, 只是猜猜, 沒有惡意. 覺得離題或是錯誤, 也可以忽略...感謝觀賞
在另一篇中我有提過 CPU使用%不一定是資料會不會塞車的依據，最主要原因是在 排序處理這件事，排序資料不能拆到不同執行緒或核心去處理
一個資料沒處理完就不能處理下一個，就是CPU有空閒也一樣，除非是不同圖表才能分流
在同一個圖表中的資料，不能分不能拆，只能排隊，而且CPU不是只有MC會去佔用，還有其他系統會佔用
雖然 windows 會去重新配置，但也不是馬上就能重配，NB的CPU反應會更慢，它要另外拉高時脈
所以我自已的PC，我是把CPU設成，永遠運作在最高時脈，不然windows會在CPU不忙時去降速、省電、降溫
需要時才去拉高CPU效能，在快市時，反應就會慢一點點，這些都是屬於windows方面的調校，跟MC無關
資料量也一樣，複製一個大檔，跟複制一個小檔，就算是容量一樣，但是速度也會不一樣
並不是資料量少就會比較快
資料量少，但筆數很多時，它要花更多時間去拆解封包
就像小汽車與大客車的概念一樣，一樣的人數，但是效率是不一樣的
其實這也可以去調校啦，只是我沒去調而已
至於新報價的部份，那是對分K以上會有明顯幫助，對tick級的幫助很有限，但還是多少可以減輕本地的報價元件的負擔
我猜如果不看 upticks/downticks, 併筆與否 兩者的 績效是差不多的
如果原先有三筆單 ABC 被併成 D, ABCD 可能價位非常接近, 所以績效差別不大.
我圖表不是開 tick, 也非都是開 IOG
只因用到 upticks/downticks, 其計算是用 tick 累計, 需要收到每個 tick.
行為跟開 tick 圖表交易差不多.
大概是這樣吧.. 我的 case 可能還是會 lag..
謝謝指教
剛巧我今天就有策略訊號發生在 萬年船 大特寫密集 tick 的時間
順便看一下我在這個時間點的成交狀況...
https://dl.dropboxusercontent.com/u/33732676/%E5%A0%B1%E5%83%B9%E6%BA%90%E5%BF%AB%E5%B8%82%E6%AF%94%E8%BC%83/2016-05-30.png
剛才詢問了TOUCHANCE，報價一年18000，但64位元的mc，只支援報價，不支援下單。所以，如果堅持要跑64位元的mc，可能得搭配下單大師使用。認真考慮中。
最近跟工程師聊過
大致上我對於一些認知與猜測是不太離譜的
如果不看量, 如果凱衛不介意開新商品, 如果客戶不介意用新商品
短時間新增一個量不正確的商品, 主機併筆處理, 定時丟單就像 DDE, 對凱衛一點都不難
(我覺得主機要看每個圖表週期多少才丟單這種作法才難, 到時候會常聽說主機沒力晚丟單)
回測就用 TXF1 就可以了, 權宜之計, 看能不能接受, 我只是從技術上面給意見.
只是我必須看量, 一定要連量都正確, 適當的併筆定時丟出應該不會影響到我, 因為我也沒看到 tick 那麼細.
100ms 觸發一次只要當時的價量都正確, 可能我就沒問題了. 我還得到一個不用等 next tick 就能收 close 的作用.
(每秒過後時間內沒更新的tick, 主機就丟一次沒量的資料來 close bar)
交易清淡時常常要晚個幾秒才會收K棒.. 這種也被當成 lag.. 但其實是 MC 自己的問題, "收K棒要等下一個tick"
真的要看到 tick 連五檔十檔報價都很在意的, 我想別家可能也無法即時提供這些資訊? 可能我要研究一下海期的資料量再說.
有沒有在別家處理 tick 很滿意但凱衛處理很慢的也可以比較看看, 也許可以知道為何別人不併筆速度很快而 MC 做不到?
如果 tick 圖就能沒問題, 其他圖應該也不會有問題, 不用搞一些有的沒的 併筆 或 新報價方式. 對, 現在是達不到.
我不知道換更多核心更快速度的電腦是不是也有幫助? 剛寫信去問等答案..
如果有幫助, 也許花個十萬準備一台 E5 12核16核 的我也覺得OK, 沒幫助我就一毛錢也不想花..
跟工程師聊聊技術, 也是不錯的, 起碼時間不是浪費在處理人性上面.
基本上艾揚這樣的方式已經不叫併筆了，算是類似 polling 的方式
要求資料的正確性的話，可能還不如接 DDE，至少大部份券商的 DDE 還有 total ticks 可以去算跟上一次的 diff 為多少
而盤後回補資料和盤中收到的不同，其實對程式交易就是一個很不友善的問題
像期交所的 rpt 檔，有去分析過的人就會發現他刻意隱藏了某些資訊 (對 tick data 來說)，所以也沒什麼價值....當然看分K以上的感覺不到
其實要作到資料無損的合併又不用像 kway 這麼誇張的 lag 並不難，就看廠商的 server 和行情報價原件有沒有能力最佳化
另外 to 萬年船兄: 建議有空可以做個測試是比較把 kway 的"下單機" 停用(不能出現在工作列) 或 uninstall 前後的差異....
錄了一小段凱衛與touchance同時傳輸的報價畫面。參考看看囉
https://youtu.be/ADZG5BmkLtY
最後能有多家數據源真是件好事，比較與競爭下，廠商的產品才會越來越好
另外，因為PK賽已全部告一段落 如有網友需要驗證或測試的可上Touchance官網申請帳號，可免費試用14天 之後再使用此報價延遲檢測軟體：MonitorQuote_v1.5.zip
萬大，請教一個問題，您的#175篇回覆中
==========
註：
依據您過去的測試來分析，我的理解是這樣：
客戶端電腦的TC數據源元件是接收到大部分的TICK，然後才在客戶端進行併筆。就是說每天TC比KW少TICK數的主要原因是因為併筆，而非收到較少的tick報價。然而，TC的延遲是比較均勻的，快慢市的延遲比較沒有太大差異。因此，TC的可能併筆機制是：
A. TC的併筆機制與快慢市無關，即並非因為快市的CPU或GPU負載高低而決定是否併筆。
B. TC的併筆機制越接近快市，CPU或GPU負載越高，併筆的數量會越增加。
關於A的方式：
以往也許是顧及有些客戶的電腦配備較差而採用這種方式，但是經過這麼多年了，我看大家的配備都在比高檔的，居然不讓客戶端有選項取消併筆? 也許是因為架構設計的因素或是商業考量吧。 但是，TC是否採用這種無條件併筆的方式，我有點存疑，因為如果是無條件的併筆，照理說快慢市的延遲應該還是可以觀察出明顯的差異。難道這個併筆的動作對於慢市時候造成的影響與快市時所能加速的部分是相同的?
關於B的方式：
如果使用這種方式，表示TC會在負載高的時候，反而更會增加併筆的動作，讓負載更增加? 而負載稍微增加的結果是能夠大幅降低(相對於KW)未併筆所帶來的延遲? 那負載的增加到底對於報價延遲的影響性為何? 這是不是好像也不太合理?
當然這些部分並不是您的業務，只是好不容易有人也在認真思考這些問題，想請教一下您的看法如何? 謝啦。
=====
另外，你說不使用凱衛數據源+凱衛下單機無法用stop單，是指內建的stopxxx那些出場函數嗎?
我用DDE或其他數據源+凱衛下單機，stop order的確是可以下單的，但是MC內建的stoploss、stopprofit那些函數的確是無法使用的 (因為我之前沒在用這些函數，沒有考慮到這個)。
無聊的上班日，從萬大這些測試所觀察到的現象，從另一個角度來思考。
以10幾年前還在做通訊系統的system modeling的經驗類推一下，希望別落後時代太多，哈哈。
1. 所有的東西，我們就先簡化成兩個完美的部分：報價 + 報價以後的所有系統。現在要考量的是，在上述的兩部分中間加入現實的TC跟KW這兩個數據源後，分別造成的影響。
2. 首先從頻域(frequency domain)來分析：
3. 其次從時域(time domain)來分析：(jitter請想成時間的延遲就好)
4. 建議的jitter模擬方式，由於如果先用個模型幫每個報價分別計算延遲加入每個tick實在太厚工，況且還要考慮到期交所送出報價的方式及數據源廠商的這些實際細節。 我覺得可以這樣，white noise部分(大概300ms)先忽略，但是至少用秒做細部回測，並且增加判斷式，若干時間內的報價變動絕對值大於一個特定值時，將下單時間延遲個1~2秒(依據萬年船大的上述測試結果)。 回測看看對你的策略績效影響有多少。
歡迎指教，謝謝。
