Linux, 工作, 生活, 家人

Embedded, Network, Programming

Wireless 的 Aggregation

電腦的世界內, 很多概念都是相同的, 有時候看看這些技術, 其實還很好玩的呢~

Aggregation 是一種概念, 我最近接觸到這個名詞是在 PreN 的 driver 上看到的, 主要的技術背景
就是將多個封包合而為一, 一起傳送出去. 主要還是減少大量封包傳輸時, 減少 Control Packet 的 Overhead.

其中主要的實作有以下幾種

  • Block ACK
  • Reducing Inter Frame Spacing (RIFS)
  • Frame Packing At MAC Layer (AMPDU)
  • Aggregating PPDU (APPDU)
  • 這些都是作用在底層的協定(Layer 2), 在實務上, 你用 Sniffer 並不會看到這些技術出現.

    首先來看 Block ACK 的機制, 這個機制就是希望在傳送的過程中, 不要再傳送 ACK
    而 Block ACK 又分成 immediate 和 delayed, immediate 是直接在 aggregation packet 傳送結束後,
    馬上傳回 ACK, 而 delayed 是等下一次傳送後再送出 ACK (心中 OS : 這種 Schema 有人用嗎…..?)
    一般來說, 大量資料傳送都會使用 Block ACK .
    而個人認為 Block ACK 也很像是 Scaling Window 的機制, 只是比較簡單, 不需要去判斷 Bandwidth.
    其實 ACK Packet 也是要耗用 Resource 去處理的, 如果這個 ACK 是用 hardware 處理也還好,
    不過如果這個 ACK Packet 是要用 CPU 去處理, 那就值得用 Block ACK 去減少 ACK 的耗用量
    畢竟一個 ACK 也是要耗用和一般 Packet 差不多的時間去處理(當然 Memory Copy 的時間少很多).

    RIFS 就比較容易理解了, 就是在 Frame 和 Frame 中間並沒有一些 Delay 或是空白的機制.
    以增加單位時間內可以傳輸的資料量.

    AMPDU
    AMPDU 圖示
    從這一張圖表可以很清楚的看到, AMPDU 就是將數個相同目地的資料, 集合成一次送出, 以減少底層 Hand Shaking 的時間, 同時也可以減少 Header 的重覆傳送, 以達到快速傳送的目地.

    APPDU
    和 AMPDU 不同的地方在於, APPDU 是 Physical Layer Header 集合在一起.

    一般來說, Aggregation 對於 Bulk Data Transfer 的效用並不大, 將 Header 減少的效用剛好在處理 Aggregation 這一段時間就補回來了, 但是 Aggregation 對於小封包就很有用了, 這時 Header 佔小封消耗的時間就比較多了.

    曾經看過 Aggregation 這樣處理的

    這樣的處理如果在 x86 內, 一點問題也沒有, 畢竟 x86 速度快, Memory Bandwidth 也大, 所以程式寫爛一點也沒有關係. 但是在 Embedded Linux 下, 畢竟資源有限.
    我們看到這個圖, 總共有幾次的 Memory Copy 呢? 答案是 3 次, 比起一般的收封包, 多了二次, 也就是三倍的 Memory 頻寬耗用量, 這還不包含 CPU 處理的時間.
    所以 Driver 這樣寫, 真是大方呀, 據我所知, 大概只有那家將文書編輯軟體內放模擬飛行的公司可以比而己…..

    這只是一個很簡單的例子, 在 Embedded Linux 下寫 Code 要特別小心, 並不是每次都有什麼 IXP420 266Mhz or 400MHZ+ 甚至是 C7 這樣高階的 CPU. 常常的狀況都是比較低階的 CPU .

    所以各位看倌可以發現, Aggregation 並沒有什麼了不起, 只是以前的概念拿來修修改改.
    在 802.11n 這些技術也己經很普遍了.

    Ref. 主要的參考文件
    Performance Analysis of Data Aggregation Techniques for Wireless LAN

    7 留言

    1. 問個問題…
      RIFS 就比較容易理解了, 就是在 Frame 和 Frame 中間並沒有一些 Delay 或是空白的機制
      Frame中間沒有Delay的話,那不就沒有競爭,永遠就只有那個人在傳資料了….@@!

    2. 文章作者的留言

      richliu

      Frame 和 Frame 中間沒有 delay 的狀況一定是對同一台機器有 bulk data transfer, 若是 Frame 和 Frame 中間要傳給其他台, 那就不會有 aggregation 機制出現了.

    3. 喔…Soga…那假設 A Node正在使用 aggregation 機制,B Node也正好要傳 Data ,那 B Node 怎麼知道 A Node 蝦米時候 Release Channel,要等待多久….@@?
      恩,剛好素偶研究所相關的研究..當時混了點..哈…^^!

    4. 文章作者的留言

      richliu

      進入 Aggregation 就要等到 Aggregation 完了以後, 再看下一個 Queue 內是什麼吧.

      這應該都是可以預期的(Aggregation 大多是 2-6 個 Packet 合為一個).

      至於 Node 的 Race Condition 應該不在本文的討論範圍內 :p

    5. MJ Liu

      Hi Richard:

      How are you recently?

      MJ Liu

    6. 😀 🙁 😈 :mrgreen: :c 😈 🙂 😈 😈 😉 😐 :mrgreen:

    回覆留言對象 取消回覆