分類: 技術

Dark Silicon 小註解

最近讀到一篇文章 [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]

1. 迎向未來消費性裝置的設計趨勢

2. What is dark silicon?

3. Is Dark Silicon Useful?

Newer New API 小註解

話說我們的 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

2. Linux网络性能优化方法简析

3. Linux kernel 2.6.24 Porting 雜記.

4. NAPI 技术在 Linux 网络驱动上的应用和完善

WIFI Direct 連線小註解

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

2. http://www.hughes-systique.com/Portals/0/Uploads/Articles/WFD_Technology_Whitepaper_v_1.7635035318321315728.pdf

BogoMips 小註解

BogoMips 顧名思義是 Bogus 的 MIPS (Million Instructions Per Second). Bogus 表示 "偽".BogoMIPS 就是假的 MIPS.

一般常用的 DMIPS (Dhrystone MIPS) 主要是測量文書處理的表現. 如果要比較 CPU 是否夠快, 看主頻率 (clock) 也是不準的. 比方說 Intel i7 是 23.860 MIPS/MHz, ARM Cortex A8 僅有 2 MIPS/MHz [1], 所以 1GHz 的 i7 還是比 2GHz 的 A8 快很多! 

為什麼 MIPS 也會有假的呢? 原因是 BogoMips 本來就不是用來比較 CPU 的計算能力的, 它是用來調校 Linux kernel 的計時單位.

假如我要 delay 1 mini-second (ms),那麼在不借助特殊硬體的情況之下, 我怎麼知道多久是 1 ms 呢? 最簡單的方法, 就是做一個簡單的迴圈,再看看繞完 X 圈後, 花掉多少時間, 然後反推繞幾圈是 1ms. 這個每秒繞幾圈就是 loops_per_jiffy.

因此在 [ref 2] 中, 我們可以看到它介紹 delay loop 怎麼做? loops_by_jiffy 怎麼做? 卻沒講到關鍵的 “為什麼?", 這部份只得去看[3]的說明, 配合 [4] 的程式. 總之, BogoMips 直接就對應到 loops_per_jiffy.

在 calibrate.c [4] 裡面有印出 BogoMips 的地方.

/* Round the value and print it */ 

		printk("%lu.%02lu BogoMIPS (lpj=%lu)n",
			loops_per_jiffy/(500000/HZ),
			(loops_per_jiffy/(5000/HZ)) % 100,
			loops_per_jiffy);

那麼一個 jiffy 是多久呢? Linux 預設為 4ms,但其實可以調整為 1~10 ms, 這也是 Linux 一個 tick 所需要的時間.至於一圈 loop 是幾條指令? 這個也不一定, 在 Linux C code 裡面,會用一個迴圈取多次的值平均.

如果只看一次,可以簡化成: 

                pre_start = 0;
		read_current_timer(&start);
		start_jiffies = jiffies;
		while (jiffies <= (start_jiffies + 1)) {
			pre_start = start;
			read_current_timer(&start);
		}
		read_current_timer(&post_start);

		pre_end = 0;
		end = post_start;
		while (jiffies <=
		       (start_jiffies + 1 + DELAY_CALIBRATION_TICKS)) {
			pre_end = end;
			read_current_timer(&end);
		}
		read_current_timer(&post_end);

		tsc_rate_max = (post_end - pre_start) / DELAY_CALIBRATION_TICKS; // loops per jiffy

至於為何 start 和 end 都要有 pre_ 和 post_, 是為了抓到剛好跨過 jiffy 進 1 的點.

[ref]

1. MIPS (計算機)

2. BogoMIPS

3. What are BogoMips

4. calibrate.c

5. Jiffies

UltraViolet 小註解

UltraViolet (紫外光) 是一種可攜式的 DRM, 如果我買了一部正版的藍光 DVD, 難道我一定要用藍光播放機才能看? 在 iPad 上看就算盜版嗎？為了解決這個不合理的狀況, UltraViolet 技術應運而生.它是範圍更大的 DECE (Digital Entertainment Content Ecosystem)的主要部分 [3].

基本上, 我們可以把 UltraViolet 分成 3 個要件來理解, 第一個是 UltraViolet 的影片, 裡面會有 DRM License. 第二個是UltraViolet Player (播放機), 裡面有 domain ID. 最後則是 UltraViolet account (帳戶), 對應到他所擁有的全部影片 (digital collection). 一個帳戶可以擁有很多影片 (digital collection),  也可以擁有很多台播放機. 

當使用者購買一部影片的時候, 這部影片就被加到這個 UltraViolet 帳號的 digital collection. 當他把這部片子放在他的第一台機器上播放時,播放機裡面當然沒有這部片子的資料. 於是播放機要去 DSP (download service provider) server 找出這個帳戶是否擁有這部影片 (check if exist)? 如果有的話, 它就可以播放, 並且把這個播放機的 domain ID 記錄下來, 下次就不用再查 (check and play).

如果一個播放機上有多個帳戶, 第一次觀看的使用者就已經把 domain ID 加給 DRM license, 好像其他帳戶也可以觀看此片. 但是 domain ID 是依據帳戶區分, 透過 DRM client 所處理的 (the DRM client gets a domain ID corresponding to the account) [1], 所以其它帳戶無法分享這項權利. 不過, 一個帳戶可以有 6 個 member,頭號 member 還可以設定其它 member 的權限.比方說, 爸爸可以指定小孩不能看限制級. 

一個帳號又可以擁有 12 台播放機 (household account).假如合法的使用者把影片拷貝到他的另外一台播放機,基本上只是重複上述的步驟, 直到超過 12 次為止.如果還想增加新的播放機, 可以先取消一台舊的播放機. 拷貝到雲端硬碟也是合法的, 但是可能會限制同時同時連線的數量, 例如 3 個.

基本上, UltraViolet 只用雲端來管制是否合法授權, 而不是管制播放機是否被授權, 這是一個不同於已往的地方.(Digital locker: By creating a digital-rights locker rather than a digital media storage locker, UltraViolet bypasses the cost of storage and bandwidth used when the media is accessed and passes that cost on to various service providers.)[2].

那麼如果我買了一片 BD, 我可以把它拷貝到硬碟去播嗎? 不行! 使用者要到網路上註冊, 然後再下載可以拷貝的版本 (if you redeem an UltraViolet right that comes with a Blu-ray Disc or DVD you’ve purchased, or buy an UltraViolet movie or TV show online, those rights are stored in your UltraViolet Collection..)[1] 而非 Ultraviolet 的 DVD 有升級的機會, 但不一定能成立.

Ultraviolet下載的檔案名稱是 .uvu [1], 而格式是 CFF (common file format.)[2].雖然 .uvu 已經商業運轉了, 但是 CFF 的細節還沒有確定. 而且播放機都是 beta 版.

假如檔案是拷貝到一個未被授權的新帳戶, 那麼 UltraViolet 會有購買的提示. 如果下載就能合法地觀看/拷貝/分享, 提供使用者足夠的方便, 倒也不失為減少盜版的對策.

[ref]

1. UV-FAQ

2. WIKI – UltraViolet (system)

3. DECE (Digital Entertainment Content Ecosystem)