___(A)____

重播用的來源檔(Raw)
HK_100503.log
檔案大小: 1,444,388 KB
此檔案為2010-05-03,HTS Server於日盛所錄下接收ComStock的港股資料(由cooper提供)

輸出給HTS的封包歷史檔(Raw)
SeqNo.HFD
檔案大小:    250,016 KB
此為GMDS輸出給HTS Server(KGQ)的完整資料內容,
包含HTS需要的封包序號、清盤、市場訊息與衍伸的欄位資料如內外盤量、前一買賣成交價等,
以及由盤後檔取得的擴充欄位如中英文名稱,交易ID,商品特性等,

HTS的歷史檔封包索引
SeqNo.HFI
檔案大小:    112,538 KB
此檔案規格以16Bytes為一個結構單位,結構內容為:
檔案位置(__int64[8]) + 封包長度(long[4]) + 發送時間(time_t[4])
提供以序號針對歷史檔快速Access的索引資訊,也可作為以後以時間模擬資料重播的依據

以Raw Data比較, 來源的 1.44GB 經過GMDS處理後, 須發送給HTS Server
的資料量僅250MB,約原本的18%不到,
其中主要原因是日盛的架構中,會有大量頻繁的Refresh資料,
而在來源資訊連結無中斷的狀況下,Refresh的內容都會跟記憶的Quote Status一模一樣,
因此單就Raw Data來說,經過變異演算處理的過程中就能節省大量資料傳輸,
而250MB的資訊量於新的壓縮傳輸機制下實際僅須傳輸120MB,壓縮約為原本的48% ,
48% * 18% = 8.64%, 也就是以通訊的部分而言,
從源資訊到HTS只須源資訊的 8.64%傳輸頻寬, 不到原本的一成, 非常驚人!


___(B)____

重播用的來源檔(Raw)
20100602-16h.log
檔案大小:   119,701 KB
此檔案為2010-06-02,由iPower提供的ComStock Log檔 (僅Level1,無Level2之5檔行情)

輸出給HTS的封包歷史檔(Raw)
20100602-SeqNo.HFD
檔案大小:     65,660 KB

HTS的歷史檔封包索引
20100602-SeqNo.HFI
檔案大小:     24,733 KB

以Raw Data比較, 來源的 119MB 經過GMDS處理後, 須發送給HTS Server
的資料量僅 65MB,約原本的55%,
原因是ComStock的架構中,有些資料須經常性的伴隨發送,
例如小數點位數,只要有價位資料就須連帶發送出來,但這個項目是完全不會有異動的,
所以GMDS以一個tag紀錄此資料,從頭到尾只須發送一次即可,這樣就能隨封包數目的數量級大幅減少傳輸資訊量,
同樣的如交易日期(ComStock有三種日期 Quote/Active/Trade Date)於同一交易日中也是不會變動的,
類似的這些都可以讓Raw Data本身透過變異演算技術的處理,就能有相當大幅度的資訊量節省空間,
資訊量節省不單是節省頻寬,包括傳遞速度與處理效率都會相對提升,
同樣的於實際傳輸的部分,可以(A)的部分來估
55% * 48% = 26.4% ,
所以從源資訊到HTS只須源資訊的 26.4%傳輸頻寬, 僅原本的三成不到, 也是驚人!

PS:
ComStock 的 Log 僅會有 Realtime 的 Refresh push, 不會像日盛中的架構會有其它多餘的Querry Refresh資料