您好,
請參考附件圖片所示, 在成交明細中, 主畫面所顯示的買進與賣出資訊, 與RTD所匯出的資料時而相符, 時而不相符, 而這個狀況並不僅此於截圖中的範圍.
向RTD SERVER訂閱的是1262.TW-ID, 1262.TW-Time, 1262.TW-Price, 1262.TW-Bid, 1262.TW-Ask, 1262.TW-Volume, 僅此6個欄位.
RTD CLIENT因EXCEL 64不能使用故是以C#另外撰寫, 此狀況下程式碼相同, 但資料的不相符並未呈現連續性,
程式檢查也無誤, 麻煩請貴司查明原因.
您好：
因您是以程式另外撰寫取值，無法確認RTD的寫法及訂閱方式
若是分開訂閱及儲存，會是各自更新，若訂閱過多，更新會有快慢問題
RTD的更新只有儘快更新，並沒有順序性
若您是依某個欄位的更新(如時間)，然後儲存該商品的其他欄位值，再對照明細，就容易會有對不上的問題
以上回覆，謝謝！
hi,
原來如此, 謝謝您的解釋, 若沒有順序性, 會出現這種問題, 技術上來說是正常會發生的沒錯.
目前是分開欄位訂閱, 觀察到約莫1秒會收到一次Notification, 取值時機便是在這時點上, 將傳出的所有訂閱欄位的值打一個包送進一個佇列再以另一並行的執行緒處理, 也就是說在那1秒當下的資料, 是同一批次處理. 訂閱數量的部份, 以截圖當下, 訂閲2個產品, 共12個欄位. (訂閱到滿檔大約收到更新的時間會0.95-1.5秒左右, 會和當時的PC負載有關)
正常的台股最短每5秒攝合一次, 所訂閱的Bid & Ask並不是BestBid<N>&BestAsk<N>, BestBid/Ask隨時在變不與成交訊息發生直接關係, 也就是沒順序性. 然而Bid/Ask或許是證交所主機有直接送出, 又或著是某種機制下結合出來的ref資訊, 但應當都與成交有強烈的直接關係, 時間似應該是要相等, 加上沒有出現快市(觀測的個股爬的像烏龜一樣), 因此.....這是會提出詢問的主要原因.
well, XQ的DDE可以不需要分開訂閱, RTD是否也OK? 訂閱的欄位名稱如何下? 單從貴司系統上所提供的設定看, 目前似乎只能分開訂閱.
日安.
(下圖為關鍵程式的截圖, 如果是程式撰寫上的問題造成這個現象, 請不客氣的指正, 很需要)
你好, 關於你提出的問題, 我想分兩個層面來回覆:
第一個層面是資料定義的問題.
交易所目前針對股票交易異動所傳送的資料主要分成兩種(封包), 一種是委託簿的更新, 另外一種是成交加上委託簿的更新.
第一種情形是股票沒有成交時委託簿卻有異動的狀態, 例如股票已經漲停了, 隔了一陣子有新的委託產生, 可是還是沒有成交, 這時候交易所會傳送目前委託簿的最新內容.
第二種情形則是股票發生成交時所送出來的資料, 這時候交易所會送出股票的成交價/量, 以及成交之後的委託簿的內容.
當交易所送出委託簿更新的資料時(第一種情形+第二種情形), XQ會同步更新五檔的委託價/委託量, 而最好的委託買價就是Bid (BestBid1), 最好的委託賣價就是Ask (BestAsk1).
如果此時有伴隨成交的話(第二種情形), XQ也會同時產生一筆新的成交明細, 欄位包含時間, 成交, 買價, 賣價, 單量, 內外盤註記等, 可是這裡要注意的是, 成交明細上面的買價/賣價, 並不是交易所更新後的五檔委託簿上面的最佳買價/最佳賣價, 而是更新前的五檔委託簿上面的最佳買價/最佳賣價.
會這樣子處理的原因是希望在成交明細上面可以讓使用者看到成交當時所搭配的買價/賣價, 同時以此為依據來推算這一筆成交是內盤成交或是外盤成交. 由於交易所並沒有公佈每一筆成交價的買價/賣價, 所以我們就以收到成交時我們"手上"的最佳買價/最佳買價為主, 而這個價格, 並不一定會等於成交之後的最佳買價/最佳賣價.
底下是今天收盤後3085這一檔商品的資料, 從畫面上可以看到目前最新的委買價/委賣價是40.25, 40.30, 可是13:30:00那一筆成交上面標示的買價/賣價則分別是40.25, 40.35, 兩者有些微的差異.
從RTD (或是DDE)所取得的Bid, Ask, 目前回傳的就是最新五檔上面的委買價/委賣價, 所以的確有可能會跟成交明細上面的買價/賣價不一樣.
第二個層面是RTD/DDE更新頻率的問題.
當我們收到交易所任何一個封包時, 在更新完相關的欄位之後, 就會主動通知RTD/DDE, 把更新後的資料傳送給RTD/DDE的client. 就我們的理解, 這部分Windows的作法可能是採用shared memory或是windows message來做跨process的資料傳遞, 如果資料異動的很快的話, 應該有可能client端不會收到我們push出去的每一次update (這一點並不是我們可以控制的). 如果發生了這樣子的情形的話, client端收到的資料就會有不同步的問題產生.
目前XQ的RTD功能並沒有支援一次可以取得多個欄位的功能, 只能每個欄位獨立訂閱. 在更新頻率很快且CPU繁忙的情形底下, 我們猜想不同步的機率就會高一些. 我們目前已經請研發團隊研究是否可以支援一次取得多個欄位的功能, 如果有任何進展的話會再通知你.
以上是針對資料定義跟傳遞方式的說明. 目前建議請你觀察一下CPU的用量, 再比對一下收到的資料內容, 比較好判斷是資料同步或是資料內容定義的問題. 如果還有其他問題或是建議的話, 也非常歡迎你再跟我們討論.
謝謝.
先感謝您的專業回覆, 明確、清晰、有用.
您提示的第一層面, 看來是我對資料所表示的內容的預設落差, 得要再多訂閱bestbid1/bestask1, 按您所說的方法嘗試組合, 才能再更進一步的觀測. 然而, 若我沒理解錯誤, 這邊的正確性還受到第二層面的影響. 第二層面, 您提到的資料不同步, 是否能理解成"掉資料"? 意思即原本應慱回3筆, 但因軟硬體以及不可預知的因素, 造成只接收到2筆或者是0筆? 或者, 指的是可能仍會收到3筆交易資料, 但由於欄位是各自更新的緣故, 因此可能這3筆的內容, 有可能某些欄位的資料會是前一筆的....?
今天, 因為要進行確認所收到的資料有沒有出現掉資料的狀況, 除了是原本的計劃外, 也因為昨天觀察到總量在XQ及RTD間有落差. 因此, 選了42檔由開盤09:00:00收集到收盤13:30:00, 統計的結果有3檔出現了成交總量上的差異, 再更進一步的進行比對, 發現並不是我所預期的"掉資料", 而是特定一筆的成交記錄中, 成交量出現差異所造成, 3檔各自都只出現一筆, 而該筆成交量也都很巧合的與前一筆的成交量相同. 對照您的回覆, 不知道這是不是就是映照了"第二層面"? 我並不確定. 比對結果請參照下圖. 
至於今日的CPU負載情況, 僅粗略的抽樣觀察, 大約落在25%-45%範圍內, CPU為i7 M620/2.67GHz, RAM: 8G. 交易時段除了XQ, 偶而會開GOOGLE Chrome, 不會做其它事.
日安.
先回覆如下
從資料定義層面而言, 目前我們只有開放Bid, Ask這兩個欄位, 這兩個欄位資料等同於 BestBid1, BestAsk1. 所以如果你想要重組完整的成交明細的話, 我的建議做法是在OnUpdateNotify時, 把目前(尚未call RefreshData之前)的Bid, Ask先存下來, 然後把這個兩個數值跟收到RefreshData時的Last對在一起, 這樣子的邏輯就跟我們目前處理的邏輯是一樣的了 (因為沒有看到完整的程式碼, 所以先猜測一下函數的內容, 如果有錯的話再請指正).
至於你提到成交量有對不起來的情形, 我目前初步的推測應該是跟RTD更新頻率有關. 不過我會請我們RD團隊做更詳細的測試之後再跟你報告.
謝謝.
狀態更新....
今日按小編提示的方向, 重新改寫部份程式碼將bid/ask & 成交資訊按前二次回覆中所提示的關鍵資訊, 進行組合.
追蹤2檔, 時間範圍13:00:00-13:30:00共258筆交易記錄, bid&ask&成交記錄與XQ主畫面的明細內容吻合.
小編最後建議的程式修改點與方法是正確的, 基於MS提供的COM Object特性, 需自行在refreshdata後以某種方式儲存下來供下一次再收到RTD server送出的updatenotify時, 於執行refershdata後再做前後次資料的比對及應用. 只是實務上, 我並不不是調整這段程式, 這段程式仍然保持接到資料就丟到佇列的單一工作來確保不會漏接或亂接, 實際調整是在另一執行緒中變更處理的邏輯與程式碼. 供參.
狀態更新(for 成交總量issue)
在上回反饋成交總量對不起來後, 我將每一次RTD notify的原始資料儲存下來, 試圖看看實際發生啥事, 在此之前, 判斷是否為一個新的成交記錄是以xq_time為key, 碰到成交量不吻合的狀況. 而這次, 由於剛好想到如果是即時撮合(如期貨), 同一個時間(計算到秒), 可能就會有數筆的交易記錄發生, 因此改以"總量"來做key. 但仍然還是會有總量不吻合的現象. 進一步的追查, 這回狀況不一樣, 是缺筆.
如下表所示, 造成缺筆的原因是因為總量變動了, 但時間未變動, 送到後端DB受到PK的限制因此沒被儲存, 而後續再收到的因總量沒變化, 也就不會觸動任何動作, 所以造成缺筆.
跟這個討論有關的, 應該就是把小編所提到的更新頻率這個層面的問題用實際的資料表現了出來, 在上回, 即便因為是以時間為key, 看到的不是缺筆而是資料不吻合的現象, 但我推敲著這二回合本質上應該都是同樣的問題, 也就是說,某一個特定時間內(pc_time), 某些欄位的資料更新了, 但某些欄位的資料並未更新. 也就是小編提到的不同步. (如果我沒理解錯誤),因此, 資料錯誤偶而就會給你來這麼一下痛的. ><!!!
我不清楚其它先進在透過DDE/RTD來接收期貨資料(即時撮合)時怎麼有效來處理這個問題, 單就目前所觀測到的數據表現, 我應該會是將時間與總量做複合Key, 同時試算一下單量與總量的變化來判斷是否為乾淨的成交記錄, 並且再多看一筆做double confirm. 這樣最快要3秒才能反應一筆成交, 以現行5秒撮合, 或許勉強可以算是一個方法. 但一但變為即時撮合就GG了.
以上供參考.
(one question: 為何是1秒 push 1次?)
last update:
good day.
自上回更新以來,發生了3-4次掉資料的現象, 每每有這種情況, 都伴隨著XQ警示音"弊叉"、XQ不能操作或輸入的現象, 最近幾次同步觀測資源的使用狀況, CPU的負載卻是下降的. 直到一小段時間後恢復正常後, CPU負載才又再提高, 估計是資料又正常的傳入後CPU開始運算. 恢復正常時, 交易明細就有可能一次跳好幾筆出來. 但過程中並沒有通知有斷線重連的訊息. (XQ警示音"弊叉"、XQ不能操作或輸入的現象, 記憶中在前幾N版程式(忘了版本號), 有一陣子發生頻率很高, 但改版後改善了很多.)
以下為今天發生時所記錄下來的資料, 時間約在09:47:00-09:48:00, RTD沒有發出資料, 恢復後, 有些個股(3433, 3533)明顯看的出來有補送出09:47:XX的資料, 但共同的狀況是都仍有缺1-2筆.
3433: 缺09:47:22; 3533: 缺09:47:20; 4968: 缺09:47:42 & 09:47:57
這個現象直覺應不是RTD的發送/接收或是更新頻率的問題, 但不確定, 由於觀察到有補送資料的動作, 而補送資料有缺漏, 因此還是更新在此, 供參.
good day.
Hi huangchin,
謝謝您的回報，小幫手將回饋資訊給相關人員參考，謝謝！
分類
12 評論