分類: 技術

網路修修

前幾天老婆一直抱怨樓下的網路慢, 我在手機裝了 APK 測試一下, 發現下載大概 3 Mbps, 上傳大概 100 Kbps 而已. 不過在小烏龜上測試, 上傳可以有 38 Mbps 的水準, 這未免也差太多了.

看了網友的文章 [1], 似乎是 AP 裡面設定的問題 – 需要手動設定上傳頻寬. 不過我的 AP 和他的不同牌子, 調了半天也沒有起色. 尤其 Tenda W309R 的韌體快 3 年沒更新了, 不由得令我惡向膽邊生, 決定把這樓上樓下的這兩個 AP  淘汰掉.

畢竟我們產品線 OTT box 兼著做 AP router 都號稱 AC1200 了, 不如趁機進版到 802.11ac wave 2 吧! 很快爬了 802.11ac router 的文章, 確認 ACXXX 的數字並不見得是愈大愈好 [2], 於是我把目標放在一位香港人小 U 推薦的品牌 [3]. 他比較重視 CP 值, 這樣應該不至於冤枉花了大錢.

在此先回頭講一下 ACXXX 是怎麼來的? 首先, 一定要把 2.4GHz 和 5GHz 的數字加在一起, 然後再灌水到整數. 不過數字大了之後, AC3200 和 AC5300 可以視為沒直接灌水! 話說 2.4G 真的可以和 5G 同時用嗎? 可以的, 根據 [2], 11ac 的部分會掉 30~40%, 11n 的部分掉 0~25%.

Mbps 2.4G 5G 5G Total
1T1R 433 433
AC600 150 433 583
AC750 300 433 733
2T2R 867
AC1200 300 867 1167
3T3R 1300 1300
AC1750 450 1300 1750
4T4R 1734 1734
AC1900 600 1300 1900
AC2350 600 1734 2333
AC2400 600 1734 2333
AC2600 800 1734 2533
AC3100 1000 2167 3100
AC3200 600 1300 1300 3200
AC5300 1000 2167 2167 5333

上表要怎麼解讀呢? 在 5 GHz 的 80MHz 頻寬的 11ac 部分 1T1R 就是 433 Mbps, 接著 2T2R, 3T3R, 4T4R 都比照辦理, 所以最高就是 1734 Mbps [4]. 除非頻寬長到 160 MHz. 那 Asus RT-AC88U (AC3100) 的 5 GHz 跑到 2167 是怎麼回事呢? 因為它是 1024-QAM, 不是 256-QAM, 速度比 1734 快 25%, 所以應該是 802.11ax 的規範 [5] .

至於 5 GHz 的部分有時候出現兩欄, 這就是所謂的 3 頻 ( 1 個 2.4 G, 2 個 5G). 一個 5G 給高速使用, 1 個 5G 給低速使用. 兩者各占一個頻寬通道, 理論上速度可以相加. 但事實上就沒那麼理想.

那麼 2.4GHz 的速度從 150~1000 Mbps 要如何解釋呢? 150 Mbps 是 11n 的 1T1R, 依此類推, 2T2R/3T3R/4T4R 就是 300/450/600 Mbps. 至於 800 Mbps 是 4T4R 的 200 Mbps, 它恰好是 11ac 的 256-QAM 在 40MHz 頻寬的速度. 而 1000 Mbps 就是 800 Mbps 快 25% 的 1024-QAM.

總結起來, AC2400 的 4T4R 應該就很夠用了. 所以買個兩台 7~8K NTD 的路由器, 應該可以讓我們家的網路升級到前所未有的地步!!! 於是我點開 PChome 的網頁, 滑鼠準備要按下去的時候, 忽然看見下方 “看此分類的人也看了…." 裡面有 “最新★1000Mbps速率“, 靠腰! 2005 年我買過左邊這個, 還放在抽屜裡面沒丟掉. 若干年後, 我又買過右邊這個 500 Mbps 的. 理論上的速度已經快了 35.7 倍.

現在居然已經進步到 1800 Mbps, 價錢只比 1/3 台高級路由器多一點點, 而且一次有兩支. 那…那…只好不讓公司 6 月業績創新高了 (各少賣了兩顆 802.11n 和 ac 的 IC), 我先買 HomePlug 頂著吧, 這樣一樓的網速可以先上到 20 Mbps. 畢竟這產品的效能打 0.1 折都堪用了.

buy-powerline1800Mbps

2016/6/5 實測結果 OK. 這樣就符合期待了.

DrSpeed-1-768x623

[REF]

  1. 光世代上傳速度過慢排除
  2. AC2400! AC3200! 是數字遊戲還是越大越好？分析最新AC WIFI製式、明白什麽規格才適合自己
  3. 嚴選性價比: 小U網販路由器/接收器五虎將列陣！- 刺激一下行貨代理吧^_^
  4. 無線傳輸速率
  5. https://en.wikipedia.org/wiki/IEEE_802.11ac

Ultra HD Premium 小註解

所謂的 UHD (Ultra HD) Premium 是由 UHD Alliance [1] 提出的規範, 主要在於和一般的UHD (4K 解析度) 劃清界線, 以便提高自身的價值. 不然大家都是 4K / UHD, 那麼比較厲害的 4K 就很可能被普普的 4K 打壞名聲.

達到 UHD Premium 的條件在今年 (2016) 的 CES 宣布底定, 內容包括:

[Content 與 device]

  1. 解析度達到 4K (3840×2160)
  2. 支援 10 bit / BT2020 / HDR

[TV]

  1. 涵蓋 DCI P3 [3] 的色域達 90% 以上.
  2. 符合下面的亮度規範之一:
    1. 最亮達到 1,000 nit [4], 最暗低於 0.05 nit.
    2. 最亮達到 540 nit, 最暗低於 0.0005 nit.

涵蓋 DCI P3 的色域達 90% 以上 – 這是甚麼樣的概念呢? 其實 DCI P3 也就比 BT.709 更寬廣一點 (更多的綠, 略多的紅). DCI P3 能涵蓋可視頻譜的 50% [5], BT.709 只有 35%. 而 BT.2020 高達 75%. 換言之, 符合 BT2020 就比 DCI-P3 大了 [6], 這條規範有點放水.

為何 TV 電視可以有雙重標準呢? 因為 OLED TV 的明暗表現遠勝於 LCD TV, 所以它整個相對區間都下降了, 理論上這樣比較不傷眼, 只是螢幕容易烙印~~~

[REF]

  1. http://www.digitaltrends.com/home-theater/uhd-alliance-explained/#:HRpZC9sXRmFE0A
  2. http://www.whathifi.com/advice/ultra-hd-premium-what-are-specs-which-tvs-support-it
  3. https://en.wikipedia.org/wiki/DCI-P3
  4. nit = cd / m2, cd = candle = 1 燭光, 除以單位面積就是 Luminance (輝度)
  5. 根據 [3],  精確地說是 CIE 1931: 45.5%, CIE 1976: 41.7%. CIE (International Commission on Illumination) 是指 CIE 的規範. 
  6. http://www.rtings.com/tv/tests/movies/hdr/wide-color-gamut-rec-709-dci-p3-rec-2020

HDCP 相容性小註解

數位的視訊輸出一般用 HDCP (High-Bandwidth Digital Content Protection) [1] 保護. 高清影片的 Full HD (full high definition 1080P) 是用 HDCP 1.X 版保護. 現在有了 4K 影片 (3840×2160 或是 4096×2160), 就改用 HDCP 2.X 保護. 

一般人很容易把 HDCP 和 HDMI 的版號搞混, 所以從 [2]  剪了一張圖如下. 除了 HDMI, DVI [3] 也支援 HDCP.

HDMI-vs-HDCP

雖然 HDMI 的版本往前相容, 但 HDCP 可不是. HDCP 2.X 和 1.X 天生就不相容. 如果用 HDCP 1.X 和 2.X 互接, 結果就是無法輸出. 不管誰是 TX (transmitter) 或是 RX (receiver) 都一樣. 世界上最主要的 HDMI receiver 就是電視, 電腦螢幕則是 HDMI / DVI 都有.

如果遇到 TX / RX 的 HDCP 版本不同怎麼辦呢? 據 HDCP 2.2 的規格 [1], 可以用轉換器來連接雙方, 例如 1.X to 2.X converter (P. 42), 或是 2.X to 1.X converter (P. 43). 目前市面可以買到 HDCP 2.2 to 1.4 的轉換盒, 價格約在 175 美金 [4]. 那麼為何找不到 1.X to 2.X 的轉換盒呢? 我猜這是因為電視已經把 2.X 和 1.X 的 HDCP key 都放進去了.

這樣的互通是有限制的. 在 [1] 的 Section 4.2.12 中規定, 如果 Content Stream 的 type = 0, 則視訊內容 (主要是 4K) 還是可以透過 HDCP repeater 傳送到下一級. 反之,  Content Stream 的 type = 1, 則不能傳給 HDCP 1.X compatible device, 以及 HDCP 2.0 compatible 的 repeater. 

要搞懂上面這段, 還要稍微說明一下 receiver 和 repeater. Receiver 本身就是最後一級, 不再把訊號往下一級 (downstream) 送. 而 repeater 會同時有上一級 (upstream) 以及下一級. 前述的 2.X-to-1.X 轉換盒顯然符合 repeater 的描述, 所以某些 HDCP 2.0 保護的影片 (Stream Type = 1) 應該會過不去.

還有一種狀況會發生 “相容性" 問題. 因為 HDCP 1.X 和 2.X 的 key 都被破解過, 所以那些壞 key 已經喪失法律地位了. 因此最上游的 HDCP  (top level HDCP transmitter) 會依序往下檢查下級的 “任何" Receiver ID 是否已經失效? 換言之, 要有個機制來儲存壞 ID 的名單 (revocation list), 而且要不斷更新這個名單. 如果名單舊了, 沒有 renew 過, 可以透過檢查  System Renewability Message (SRM) 的簽名 (signature) 是否正確來判定, 舊的版本要換成新的.

SRM 一代是 5116 bytes, 理論上非揮發記憶體夠大, 就可以每代多 5KB 不斷更新. 不過規範只要求至少支援 5KB, 如果只有 10KB, 那就存第一代和第二代即可. 示意如下圖 [1].

SRM-Size

[REF]

PGP 小註解

PGP [1] 是 pretty Good Privacy 的縮寫, 我們可以用 PGP 幫我們的文件 (含信件) 加密或是驗證. 如果大家收到一個 .PGP 的檔案, 這個文件應該是用對方的 key 和你的 public key 所加密的. 因為你已經把 public key 給過對方, 那麼收到 .PGP 時也不會太意外.  如果對用法上不熟, 可以參考 [2].

有一種加密方式是把整封信加密, 此時很有趣地, 看到 .pgp, 解開之後發現是信上的 logo 而已. 真正信件的內容是穿上 ASCII armor [3] 形式的亂碼. 例如:

—–BEGIN PGP MESSAGE—–
Version: 10.3.2 (Build 15238)
Comment: This message is confidential
Charset: utf-8
…
vp5hQ3ROXrZ7KVeyDlb3yD2/cmZbznGTN7Rowt2LOuec4CjcOlRB/q3XaalhoXnj
…
—–END PGP MESSAGE—–

ASCII Armor 的用意是避免 binary 形式傳檔案時, 剛好出現不應該出現的 pattern, 而造成 gateway 的問題, 或是被當作病毒等等. 因此用 binary to textual 逐 byte 轉成 ASCII code. 此外, 根據 [4], DOS/UNIX 的換行符號通常都可以被自動克服.

這時候, 明眼人都看得出來這段文字就是 PGP 檔案. 所以把  —–BEGIN PGP MESSAGE—– 到 —–END PGP MESSAGE—– 剪下來, 貼到一個新的檔案上, 然後存成一個檔案, 就可以解密它.

我用 Kleopatra [5] 試驗的結果, 只要不是存成 .PGP 檔, 沒有附檔名, 甚至 rename 成 .ZIP 檔或是 .out 檔, Kleopatra 都能將它正確解密, 並且生出 XXX.out 檔. 不過存成 .PGP 檔就不行了. 至於用 GoAnyWhere Open PGP Studio [6] 去解 ASCII Armor, 還沒有成功過.

使用 Kleopatra 容易遇到一個小問題, 第一次可以正常使用. 如果當掉了, 第二次就會開不起來, 抱怨找不到 libkleo.dll. 本來以為它是被防毒軟體誤殺. 想不到是這個軟體的烏龍. 到 Kleopatra 圖示點右鍵, 選 “內容", 把開始位置的 “C:Program Files (x86)GNUGnuPGbin" 砍掉 bin 就 OK 了. 這個 bug 被報了兩年, 據說到 2016/4/8 的版本才解掉 [7].

[REF]

  1. 良好隱私密碼法
  2. 文件認證——Pretty Good Privacy (PGP) 簡介與應用
  3. ASCII-Armor 這個 link 很好, 但是點進去要等一段時間廣告.
  4. Line Breaks in OpenPGP ASCII armor
  5. https://www.gpg4win.org/
  6. http://www.goanywheremft.com/products/openpgp-studio
  7. Bug 333535 – System Error on initialisation – libkleo.dll is missing

SBC vs aptX

這兩個音訊格式都是藍牙所使用的. SBC = sub band CODEC [1], 關於何謂 sub-band, 從頻域來看, 聲音從低頻道高頻都有, 因此可以分成一個個的區段, 這就是 band. 好比手機訊號有 900M, 1800M 這樣.

但人耳對於不同頻段的感知能力不同, 說話的高低音 (300~3KHz) 我們比較容易分辨, 但是對於 16KHz, 20KHz, …這種高音, 聽起來都是很尖而已, 甚至木耳一點就聽不到. 所以我們可分而治之, 在不同的頻段給予不同程度的壓縮. 這就是 SBC.

對於藍牙系統來說, 支援 A2DP (Advenced Audio Distribution Profile) 就要多處理 audio 的壓縮、解壓縮. 如果硬體不夠力, 這樣的小工作也是一個負擔. 在 SBC 的規範當中, 最高可以支援 48KHz 採樣, 單聲道 198 Kbps, 雙聲道 345 kbps. 即使計算量不算太高, 這 bit rate 卻也不低.

至於 aptX [3], 原本叫做 apt-X, 被 CSR 買了之後改為 aptX. Qualcomm 在 2015 年完成對 CSR 的併購, 所以 aptX 算是 Qualcomm 的私有規格. aptX 雖然複雜度比較高, 但仍然是一種 sub band CODEC. 它的好處在於採樣率下降到 44.1 KHz, 所以單聲道最多 176 Kbps, 但雙聲道可以 352 Kbps.

相形之下, aptX 有何種誘因讓大家採用呢? 主要是它的 encode / decode 速度較快. 在 CSR 的官網, 他們大喇喇地宣稱用了其他 audio CODEC 會導致 AV 不 sync [4]. 不過這個說法並不公正. 只不過是因為 audio 到了藍牙裝置後, 被系統視為  HW 輸出, 所以愈接近 real time 的 software audio CODEC 就不會和 video free run. 把它當作一種廣告詞就好了.

[REF]

  1. SBC (codec)
  2. [無線科技] 立體獻聲藍牙人間：淺談Bluetooth技術
  3. aptX
  4. https://youtu.be/e5aG4qIVqSw