GMDS應該比較快的理由

張貼日期：Dec 20, 2010 6:27:28 PM

先前都有提到透過壓縮的機制使實際要傳輸的資料能以較少的位元組數來傳遞,

於經過電路不論是數位(並列)還是類比式因為所須傳輸位元組較少而達到傳輸較快的目的,

現在則針對Lan上的乙太網路說明GMDS應該比較快的理由

1. 乙太網路是一個封包框架的架構,每個封包框架約可提供1.4KB的資料描述與承載空間,

    最基本的描述是來源與目的的MAG Address(ipconfig /all 中的 Physical Address)各6個Bytes,

    在此基礎上開發了IPX,SPX,IP,UDP,TCP,ICMP...等各種封包協議的應用

2. 由於1.的原因,在乙太網路上不論用任何封包協議傳輸1個位元組或10Bytes還是100,1000Bytes

    都是同樣是以一個乙太網路封包完成傳遞,所需時間皆相同

3. PC上網卡透過卡上的(Rx)Cache緩存由乙太網路上所接收封包

    OS再透過硬體插斷透過匯流排由卡上的Cache取得封包再緩存於OS的(Recv)Queue中

4. 由於透過硬體IO是相對慢的動作,因此不是一個封包一個封包去IO取得,

    所以3.的處理過程中,往往是一個IO之後是數個封包

5. 以Multicast個概念,不論是透過軟體或硬體,將這些封包發佈到另一個Lan中時,

    則是逐一將封包置入OS的(Send)Queue中,在對應的硬體插段發生時作實際的硬體IO將Queue中的所有封包送至網卡上的(Tx)Cache

    之後網卡依據乙太網路的規範將封包逐一送入網路中

6. 由於2.中所述的乙太網路架構與4. 5.所描述的硬體與OS間之處理程序,

    再搭配GMDS所設計的傳輸技術,可以將數個Multicast封包只透過1個乙太封包完成傳輸,

    因此在有相對多的資料量下,傳輸速度是原本的數倍

7. 同樣的理由,如果有第二層,第三層架構,在原始封包內容相對小的狀況下,還會有堆疊加成效果,

    因為在未達一個框架限制之前,可能第一層合併3包成一包又合併2包成一包,

    而第二層IO狀態合併2包,則合併後的這一包其實已是5包的結果

8. 綜合以上的結果,理想狀態下GMDS可以在多層傳輸後仍無明顯的時間差異

9. 超越市場第一層的資訊架構的行情速度是可行的,也就是行情VPN的交易所端即建置GMDS,

    透過GMDS的方式於VPN本地還原所需的Multicast環境即可(不過要看交易所端是否能接受這麼做)

10. 如果9.不可行

      那麼類似的行情架構,如果都是在VPN之後的第二層架構上才開始服務則GMDS有絕對的優勢,

      倘若讓GMDS於相同的Multicast才開始服務作比較則沒有效果

11. 關於RTC(Real Time Clock)以高精制(1ms以下)作時間量測的技術說明,

      由於此類技術是透過硬體Port IO取得RTC上的資訊,因此這個硬體IO動作是相對慢的,

      而如果GMDS原本是透過一個乙太網路封包即以取得3個Multicast原始封包,時間絕對是同時,

      但測試方式是3個Multicast封包逐一呼叫RTC紀錄時間,會變成因為硬體IO而造成有時間落差

      (以物理學來說就是測不準,因測量而產生干擾,強調空間位置則時間測不準,強調時間精確則位置測不準)

12. 基於GMDS核心發展的傑出資料處理能力,在龐大的資料處理需求下自然取得效能與速度絕對優勢,睥睨所有系統!