下圖是 2013 年 Q3 NCC 要釋出的頻段: 700, 900, 和 1800 MHz. 其中 2600 MHz 已經給 WiMax 了, 它也算是 4G 吧！
因為上行和下行頻帶都是對稱的, 所以就只畫了上行. 只要知道 Down link 的起點, 其他照著加就是了.
每個頻帶的上面寫著該頻段原來的擁有者, 下方就是整理好要賣的頻帶. 可想而知, 4G 的全面啓動就意味著 2G/3G 被淘汰, 幾乎沒有共存的空間.
畢竟, 淨土就那麼一點點大. 除非政府讓 C5 這塊先試運行. 不然 2015 應該會有一波換機潮吧!
[補充] 1800 MHz 原先釋出的頻帶不是整數, 所以不好對齊. 另外, 和信在 2010 年 1 月1 日已經併入遠傳.
[ref]
原本我以為免費 browser 盛行之後, Opera 就沒搞頭了. 想不到他們和 Google 聯手在今天四月推出了新的 web browser engine – blink, 放到了 Chrome 28 版和 Opera 15 版.
大家都知道 Google 有 Chrome browser 而 Android 用 Webkit 當預設的瀏覽器, 但他們原先其實都是 Webkit [1]. 而 Webkit 是 Apple 從 open source 的 KDE project 中分支出來的, 它借用了 KDE 的 KHTML engine 和KJS Javascript engine. 由於 KDE 是 open source, 當然 Webkit 也必須是 open source, 只是 KHTML 發展成 WebCore, 而 KJS 變成 JavaScriptCore.
等到 Apple 熟悉了瀏覽器的技術, 就做出了 Safari, 並且聲其中牽涉到 OS 的技術, 所以不用 open source. Google 同樣是先加入 Webkit 計畫練兵, 並且在 2006 年另外開了一個 Chromium 的 open source project 另外發展一套瀏覽器 [2].
Google 在 Chromium 計畫的主要成果包括 V8 Javasceipt 引擎, sandbox, 黑名單, 與無痕瀏覽等等. 其中, V8 就曾經被放進 Android 4.0 的 Webkit 當中. 當然最好的東西都進了 Chrome browser. 最後 Google 的人開始嫌棄 Webkit [3], 並且打算在 Android 5.0 把它拔掉, 換成自家的 browser.
話說, Google 和 Apple 是 Webkit 這個 open source project 的最主要的 reviewer, 自己在管的計畫為什麼還嫌東嫌西呢? 其實 Chome 之於 Google 就像 Safari 之於 Apple, 自己有了獨到的心得之後, 難免就不想再和別人分享. 上次 Chromium 最傑出的成果是 V8 JavaScript engine, 而這次 Google 的突破點在於 HTML engine – blink. 看來內外功都已經練成了.
Chrome 的 blink 比 Webkit 的 WebCore 強在那裡呢? [ref 3] 首先說到 multi-process, Google 認為 Webkit 在這個情境下會拖慢速度, 而 blink 當然只要一眨眼. [Ref 4] 則大致介紹了 blink 在 multi-process 的設計概念. 這個可以單獨寫一篇, 初步的理解就是改了 data structure, 用空間換取時間.
那麼 Opera 又扮演什麼角色呢? 它最近宣布放棄開發瀏覽器 [3], 準備擁抱 Chrome. 這件事引起許多人在網路上討論. 原來這也不是因為 Opera 有什麼高瞻遠矚, 而是 Opera 的 Mobile OEM 業務已經被 Android 打掛, 萎縮到不值得經營了. 它在 2012Q4 的業績就比前一個年度下滑 89% [5].
相對地 Opera 在 device OEM 的部份還有成長, 只要把內核換成和 Android 一樣, STB 上的 Opera browser 將會和大家用的 Chrome 或 Safari 更加神似. Opera 廢掉自己的武功, 雖然可以省下研發的費用, 但也有人說 Opera 的企業精神已經喪失. Google 殺人於無形, Opera 投敵求生, IT 業真是可怕.
[REF]
1. Webkit
2. Chromium
最近讀到一篇文章 [1] 說到 Dark Silicon 的問題, 並且把它翻譯成 “蚊子矽電路". 矽電路容易理解, 但是和蚊子有什麼關係呢? 雖然這引起了我的好奇心, 不過始終得不到解答.
那麼, Dark Silicon 又是什麼呢? 它是指 IC 裡面不能開的電路. 出於省電的考量, 所有的 IP 不能同時工作. 這就好像公司有 15 個人上班, 發電機卻只能支援同時開 10 盞燈和 10 台電腦. 如果某人沒輪到供電, 就只能在黑暗 (Dark) 中發呆, 順便餵蚊子? 嗯, 也許這是蚊子矽電路名稱的由來, 哈!
根據 [2] 的說法, 在 22nm 的時候, dark silicon 會佔 IC 面積得的 20%, 而到了 8nm, dark silicon 將會佔 50%. 這樣就很有趣了, 問題有這麼嚴重嗎? 讓我們來看一下論文 [3].
論文說 dark 或 dim (昏暗的) silicon 並不是 IC 設計師故意造成的, 而是製程本身的特性使然. 假設我們從 32nm 進步到 22nm, 那麼有一個 Scaling factor – S = 32/22 = 1.4X (40nm 進步到 28nm 也是一樣的道理.) 理論上, 同樣面積的 IC, 電晶體多了 S2 (1.4 x 1.4 = 1.96 約 2X) 倍, 而電晶體的速度 (transistor switching frequency) 又可以增加 S 倍, 所以我可以得到效能 S3 (1.4 x 1.4 x 1.4 = 2.74 約 2.8X) 的新晶片.
由於 power = quantity (電晶體數量) x Capacitance (電容) x Vdd2 (電壓) x frequency (頻率), 所以早期每當製程進步 S, power 就增加 S2 x 1/S x 1/S2 x S = 1, …嗯, 沒增加. 可是到了次微米時代, threshold voltage 如果持續降低, 則漏電電流也會愈來愈大, 導致功耗增加. 因此 Vdd2 不能再降了, 變成定值 1, 與製程無關. 新的功耗也變成 S2 . 為了抵消功耗增加, 只好把 utilization 減少. 看下圖 (from [3]) 的說明, 若每一個小方格是一顆 CPU, 在功耗不變的考量下, 製程的進步就會帶來 dark silicon.
左邊的 4 核 IC 在 65nm 是 4 格大小, 到了 32nm (S = 2), 同樣的面積可以放下 16 個 core. 為了不增加功耗, 還是跑 1.8 GHz, 那麼 3/4 的 IC 面積即使放了電路也都不能動, 不然功耗會增加. 換言之, 3/4 面積變成 dark silicon (右下角的方案). 為了解決這個問題, 我們讓 50% 的 cell dark, 50% 的 cell dim. 這新的灰色的 4 核, 其實每一核的電晶體數目不變, 而面積都比原先大一倍, 使用率是 1/2 (右上角的方案).
以上講的都是學術上的思路. 真實情況下, 我們會希望 IC 設計不用改, 換了製程之後, 面積變成 1/S2 , 速度變成 S 倍, Utility 不變, 功耗 (1/S x 1/S2 x S) 下降. 但考慮漏電電流很大的情況下, 功耗和預期的 1/S2 相比, 可是差很大, 就只是小降而已.
[ref]
話說我們的 kernel 從 2.6.12 進版到 2.6.34 時, 網路速度似乎有點下滑. 為了瞭解這個進版對網路 driver 有什麼影響, 我發現了這個改良版的 New API – Newer New API.
原來的 New API [1] 是做啥的呢？ 它是為了避免 CPU 太忙所產生的處理方式.
早期網路 driver 在收到 packet 的時候, 都會發 IRQ （interrupt request）去通知 CPU 搬 data. 隨著網路的速度愈來愈快, CPU 漸漸就沒辦法做這麼瑣碎的雜事了. 假如一個 MTU 是 1500 Bytes, 那麼, 15 Mbps 的影片就會在每秒發出 15,000,000 / (1,500 x 8) = 10000 / 8 = 1250 個中斷. [2].
只要網路流量低, 那麼 IRQ 還是可以用. 一旦網路流量超過某個界限, CPU 就改用 Polling (輪詢) 的方式去撈 data. 這就是 NAPI 的基本觀念. 由於不是看到 packet 就發 IRQ, 把更多 data 留在 buffer 裡, 也可以減低 re-order 的機會. 萬一 CPU 根本處理不了那麼多 data, 新的資料會直接覆蓋掉舊的, 不會讓 CPU 到了來不及的最後關頭才丟棄資料 [1].
在這組 API 裡面, 支援了設定網卡工作模式 (IRQ or Pollng), 進入或退出工作模式的幾個 function call.
到了 Linux 2.6.24, NAPI 的名字仍然被沿用, 但是內容已經更新了. 主要的改變分為幾點:
1. NAPI 和 net_device 不再是一對一, 一個 network device 可以支援好幾個 port, 每個 port 根據自己忙碌的程度, 決定它在哪一種工作模式.
2. 註冊輪詢的 API 異動
void netif_rx_schedule(struct net_device *dev);
→
void netif_napi_add(struct net_device *dev, struct napi_struct *napi, int (*poll)(struct napi_struct *, int), int weight)
也就是說原來可以加入輪詢的 API 多了指定獨立資料結構的 struct napi_struct *napi, 輪詢方法的 int (*poll)(struct napi_struct *, int), 也把 weight 從 dev→weight 的資料結構中拔出來明確指定.
3. 輪詢的 prototype 也改了, 不再依據 device.
int (*poll)(struct net_device *dev, int *budget);
→
int (*poll)(struct napi_struct *napi, int budget);
4. 關閉輪詢功能的 API 當然也改了, 以前是關 net_device, 現在是關某個輪詢方法.
__netif_rx_complete(dev)
→
void netif_rx_complete(struct net_device *dev, struct napi_struct *napi);
更細微的改動我就不列了. 我好奇的是, 如果 driver 是用舊的 NAPI 寫的, 直接拿到 2.6.24 以後的版本去用, 會不會註冊不了 polling function, 只好一直發 IRQ 而導致 performance 不好呢？還是根本編不過?
今天已經快睡著又變餓了, 明天再繼續研究這個問題.
[後記]
看了 Wireless network 的 driver, 裡面果然都是用 tasklet.
[ref]
1. New API
WIFI Direct 是 WiFi 聯盟所提出的規格, 目的在於讓兩個無線裝置不透過 AP (access point) 就直接溝通. 或曰, 不是有 TDLS 嗎? WIFI 聯盟說了 [1]:
TDLS operates in the background of a Wi-Fi network to optimize performance, while Wi-Fi Direct-certified devices can quickly connect to one another while on the go, even when a Wi-Fi network is unavailable. Many devices will be certified for both solutions and use them in different situations.
WIFI Direct 不需要 AP 仲介, 也不需要已經建立的網路.首先雙方以 discovery 發現對方.如果有一方講話有人在聽的話, 對話就成立了. 這就是 search-listen 組合, device 1 發出的 probe request 收到了 device 2 的 probe response 的回應.
此後 device 1 開始 formation, 送出 GO negotiation request, 等待 device 回應 GO negotiation response, 如果對方沒有進入 formation 的階段, request 會得到 fail 的結果. 若是能夠正常回應, 這樣就可以準備 GO 了嗎?! 非也, 這裡的 GO 並不是英文 go! go! go! 的那個 go, 而是 group owner 的縮寫. Device 1 是 client, 而 device 2 是 group owner, 相當於一台 AP 的角色. 所以一個 GO 也可以有很多 clients.
那麼如何決定誰是那麼如何決定誰是 group owner 呢? 方法就是圖中的比大小. Device 1 在送出 request 的時候, 會附上 intent = 3.可惜 device 出的 intent = 3, 既然 10 > 3, 所以 device 2 就當 GO. 要是雙方不巧平手的話,就看雙方誰做莊? 做莊的那個會在 tie-breaker bit 註明, 這個值是隨機的.如果雙方都出王牌 (intent value >= 15), 搶著當 GO, 那麼連線就會失敗.
雙方角色確定之後, 還要有一個 GO negotiation confirm 才算完成 request / response / confirmation 三部曲.這是 Formation 中決定角色的完整步驟. 到了 Formation 的後段, P2P 的 device 要互相鑑別對方 (authentification), 然後 client 要發 association request 和獲得 association response, 這樣才和 GO 完成所有的 standard formation 的工作.
另外一種 formation 叫做 persistent.它可以把 group 中的成員記下來, 後續再連線時,可以直接邀請 (invite) 對方加入 group.Invitation 也分成 3 種, 就是 GO 請 device 加入變成 client, 或是 client 邀請 device 變成 group member (前兩者 invitation request frame = 0), 以及先前 persistent formation 的 GO (一定要有 GO) 和 client 重建當時的連線關係 (invitation request frame = 1).
Persistent invitation 的好處就是不需要複雜的認證,只是做 WSC (WIFI simple configuration). 而 GO 要負責在 invite response 時, 提供這一堆資訊:P2P Group BSSID, Channel List, Operating Channel and Configuration Timeout attributes to indicate the Group BSSID, potential Operating Channels, intended Operating Channel and any GO Configuration Time 讓連線快速恢復上次的狀態.
[ref]
1. http://www.wi-fi.org/knowledge-center/faq/what-difference-between-tdls-and-wi-fi-direct
Cash Chou's Blog 