Web Workers 小註解

如果看到 dedicated worker 這個名詞, 可能會讓人聯想到專注的工作者. 而 shared worker 就像是共用的人力資源. 其實無論 dedicated worker 或是 shared worker 都是 web worker 的一種, 而 web worker 當然不是指網路工作者.

Web worker 是 HTML (特別是 HTML5)  的一個 feature, 它允許一個以上的 thread, 特別是在有任務很重的 Javascript 的狀況下, 有效率地在 browser 上執行.

在未支援 web worker 的環境下, 必須等到 Javascript 被執行完之後, 才能執行完某個 thread. 這使得 Javascript 所花的時間不能夠被隱藏起來, 而降低了執行的效率.

Browser 支援 web worker 之後, 它定義了 run Java 的 API. 多個 Javascript 都可以被放到 background 執行. 而且這些 Javascript 不會直接 access DOM, 只是透過 message passing 來收發 event.

舉例來說, 傳統的 HTML 會花一段 code 寫 Javascript, 然後用 <Javascript></Javascript> 包起來, 接著在 HML 中調用 Javascript 所定義的 function.

但 Web worker 的做法, 直接在 <Javascript></Javascript> 中間, 把 Javascript 指定給 worker 管理. load 一個 Javascript 或是關閉它的方式如下:

var worker = new Worker("worker_script.js");
 
worker.close();

把 message 傳給 worker, 或是從 worker 接收的方法如下:

worker.postMessage("Hello World!");

worker.onmessage = function(event) { do something }

Dedicated worker 表示 worker 被 create 出來的時候, 它的 message port 就已經被產生了, 例如上面這種寫法. 它的最大優勢就是簡單.

shared worker 依據 port 來共用 worker. 表面看起來和 dedicated worker 只差一點點:

var worker = new SharedWorker("worker_script.js");
worker.port.onmessage = function(event) { do something }

但實際上, Javascript 裡面會有一個 assign port 的動作, 再為 port 設定一個 listener:

var port = event.ports[0];

port.onmessage = function(event) { do something }

透過這樣的'方式, 多個 window 都可以共用一個 worker thread.

由於 dedicated 和 shared worker 的特性不太相同, 號稱支援 Web worker 的 browser 也未必同時支援這兩種模式. 我們可以透過傳回值來確認 browser 是否提出支援.

// Test if Dedicated Web Workers are available
if(window.Worker) { g_bDedicatedWorkersEnabled = true; }

// Test if Shared Web Workers are available
if(window.SharedWorker) { g_bSharedWorkersEnabled = true; }

[ref]

1. WIKI

2. Web Workers Editor's Draft 4 October 2011 [Complete!]

3. Javascript Web Workers: Opera 10.6 Beta Supports SharedWorkers

4. An Introduction to HTML 5 Web Workers  [Best!]
 

WebGL 小註解

WebGL 正如其名, 具有 Web + GL 兩種性質. 它是一個 3D rendering 的 API, 修改自 OpenGL ES 2.0, 而且它使用 Web browser 當作 middleware. 只要有 browser, 就可以用 HTML 來畫 3D.

當然, 此時 WebGL 需要借助 HTML 的 CANVAS. 下面是 CANVAS 的一個例子, 說明 canvas {} 可以畫出圖來. 只不過這個例子是 2D 的, 而不是 3D 的.

大家可以發現, canvas 需要先做一個類似宣告的動作. 以便取得 ID (假設是 xxx 或是上面例子中的 tutorial.

var canvas = document.getElementById(‘xxx’);

然後再用這個 ID 取得 context, 有了 context  就有 drawing buffer. 和其他語言一樣, 第二次用同樣的名字去 getContext, 只會傳回同樣的內容, 不會再 create 新的  object . 

var ctx = canvas.getContext(’yyy’);

至於 drawing buffer 的內容, 主要是 color (8 bit), depth (16 bit), 和 stencil (模板 8 bit).

那麼 view point 呢? 表示方法如下, 由四點所組成的矩形構成四個參數:

ctx.viewport(0, 0, canvas.width, canvas.height);

 在陰影處理的部分, WebGL 支援 GLSL (OpenGL ES Shading Language). 

最後要提一下 DOM (document object model), WebGL 也會用到它. 因為 DOM 是跨 HTML, XHTML, XML 的資料表示方法. 所以 WebGL 的 function 和 interface 是用 DOM 來描述的.

對了! 據說所有知名的 browser 都打算支援 WebGL, 除了 IE9 不想放棄自家的 DirectX 之外.

[ref] WebGL Specification V1.0

 

MCS 小註解

關於無線網路的速度問題, 有一個標準的指標 – MCS (Modulation and Coding Scheme). 只要用 MCS 就可以概略知道傳輸速度, 而不需要講出實際的數字.

下表取材自 WIKI, MCS index 就是指速度的指標. 比方說我支持到 MCS7, 他支援到 MCS15 之類的. Spatial Stream 是指空間流或是空間串流, 要明白空間串流就要先明白空間分集. 假如在訊號的發送端有多個天線, 而每個天線的訊號都會透過不同的路徑到達接收端的天線, 這樣就構成了空間的分割或是分集. 如果天線不夠多支, 也就無法做到分集. 11n 的規範最多就是支援 4 支天線.

Modulation type 就是通訊原理裡面講的調變方法. Coding rate N/M 是指傳送 M bit 時, 裡面有 N bit 是 data, 當然 M – N 就是 redundant 了. Redundant 不是沒有用, 反而可以防錯或是校正錯誤.

20 或 40 MHz 是通道的頻寬, 這個一看就知. 不過這個 GI 呢?如果傻傻去 Google GI 不會有什麼好下場. 由於 GI 的單位是時間, 所以可以猜到 I 表示 Interval. 對, GI 就是 Guard Interval. 在兩個 OFDM 的 symbol 之間的傳送間隔即為 GI. GI 愈短, 則傳輸速率愈高.

在 4 根天線的狀況下, 距離不要太遠 (coding rate 高) 的話, 11n 可以達到 600 Mbps. 而一開始講到的 MCS7 和 MCS15, 其他的條件都是一樣的, 只差在空間串流的數目. 這點可以從天線的多寡很快判斷出來, 沒有兩根天線是不可能做 MCS15 的.

MCS
index
Spatial
streams
Modulation
type
Coding
rate
Data rate (Mbit/s)
20 MHz channel 40 MHz channel
GI = 800 ns  400 ns  GI = 800 ns 400 ns
0 1 BPSK 1/2 6.50 7.20 13.50 15.00
1 1 QPSK 1/2 13.00 14.40 27.00 30.00
2 1 QPSK 3/4 19.50 21.70 40.50 45.00
3 1 16-QAM 1/2 26.00 28.90 54.00 60.00
4 1 16-QAM 3/4 39.00 43.30 81.00 90.00
5 1 64-QAM 2/3 52.00 57.80 108.00 120.00
6 1 64-QAM 3/4 58.50 65.00 121.50 135.00
7 1 64-QAM 5/6 65.00 72.20 135.00 150.00
8 2 BPSK 1/2 13.00 14.40 27.00 30.00
9 2 QPSK 1/2 26.00 28.90 54.00 60.00
10 2 QPSK 3/4 39.00 43.30 81.00 90.00
11 2 16-QAM 1/2 52.00 57.80 108.00 120.00
12 2 16-QAM 3/4 78.00 86.70 162.00 180.00
13 2 64-QAM 2/3 104.00 115.60 216.00 240.00
14 2 64-QAM 3/4 117.00 130.00 243.00 270.00
15 2 64-QAM 5/6 130.00 144.40 270.00 300.00
16 3 BPSK 1/2 19.50 21.70 40.50 45.00
17 3 QPSK 1/2 39.00 43.30 81.00 90.00
18 3 QPSK 3/4 58.50 65.00 121.50 135.00
19 3 16-QAM 1/2 78.00 86.70 162.00 180.00
20 3 16-QAM 3/4 117.00 130.70 243.00 270.00
21 3 64-QAM 2/3 156.00 173.30 324.00 360.00
22 3 64-QAM 3/4 175.50 195.00 364.50 405.00
23 3 64-QAM 5/6 195.00 216.70 405.00 450.00
24 4 BPSK 1/2 26.00 28.80 54.00 60.00
25 4 QPSK 1/2 52.00 57.60 108.00 120.00
26 4 QPSK 3/4 78.00 86.80 162.00 180.00
27 4 16-QAM 1/2 104.00 115.60 216.00 240.00
28 4 16-QAM 3/4 156.00 173.20 324.00 360.00
29 4 64-QAM 2/3 208.00 231.20 432.00 480.00
30 4 64-QAM 3/4 234.00 260.00 486.00 540.00
31 4 64-QAM 5/6 260.00 288.80 540.00 600.00

DHCP 之 APIPA

最近客戶又要 daily review 了, 趁著開會前, 老婆還在煮晚餐的空檔, 整理一下客戶發的 bug.

APIPA 全名為 Automatic Private IP Addressing, 也就是自動獲取 IP address 的規範. 當我們使用 DHCP (dynamic Host Configuration Protocol) client 的時候, 機器會先發出 discover 的封包, 找尋 DHCP server.

此時, 機器不知道自己該拿哪個 IP, 所以會先用 0.0.0.0 去廣播. 如果找得到 DHCP server, DHCP server 就會分配一個沒人用的 IP 給剛才的機器.

由於 IP address 有限, 在人來人往的麥當勞, 發給客戶的 IP 都是動態的, 如果租約到期, 這個 IP address 就會被回收. 如果是 automatic allocation, 那麼分到 IP address, 都可以一直用下去. 例如公司有線網路的 DHCP 就適合這麼做.

但是找不到 DHCP server 又怎麼樣呢? Windows 2000 以前的做法是保留 0.0.0.0, Windows 2000 以後的做法就會隨意用 169.254.xxx.yyy 的位置, 搭配 255.255.0.0 的 submask 來充當例外時的 IP 設定. 這樣就算沒有 DHCP server, 仍然可以達到自動獲取 IP 的目的.

Quadrant Benchmark 小註解

 Quadrant  是 Aurora 公司推出的軟體, 功能是測量 Android 系統的效能. 相較於 Windows 有官方的性能評分工具, 但是分數的間距很小; Quadrant 比較像是 3D Mark 那樣, 能夠給出比較拉得開的分數. 除了總分, 也可以對 CPU, Memory, IO, 2D 和 3D 做出評價 (Advanced 以上的版本).

假如不用 Quadrant, 有沒有其它的代替方案呢? 有, 前三名還包括 Linpack 和 Neocore. 據說 CF-Bench 也可以測多核心 Android 系統的效能, 差別在於它不測 GPU.

只要用 Google 圖片去 search quadrant, 就可以看到很多 “第一名" 自拍. 我看到最厲害的是 3278 分. 客官啊, 這個 bench mark 的 bench mark 是 1 千多分, 破 3000 分是怎麼來的呢? 原來是有人破解了 Qudrant 的計分標準. 它的罩門在於 IO 速度這一項.

這位 Cyanogen 老兄發現, 只要把 Qadrant 測試用的目錄, 設在用 memory 模擬的 file system 下面, 就可以靠著 IO 方面的優勢, 獲得不可思議的高分. 引用 WIKI 的說明, 下面原文中提到的 tmpfs, 就是用 mount -t tmpfs -o size=1G, nr_inodes=10k, mode=0700 tmpfs /space 之類的指令, 把 1GB 的記憶體, 指定給 space 這個目錄夾使用. Quadrant 拿這個資料夾去測 IO, 當然就不察而給予過度高估的評價.

In Cyanogen’s tweet, he says he was able to exploit the flaw to get obscenely high Quadrant benchmark scores by mounting “a tmpfs over quadrant’s data directory.” A tmpfs, or temporary file storage system, can artificially inflate a device’s I/O score and provide unreal benchmark improvements.

這篇文章的原作者提到, 既然 Qadrant 有 bug, 所以參考意義不大. 不過我想到如果各家廠商要 PK Qadrant 的時候, 說不定也可以用這個技巧來欺騙對手…哈!

[ref] http://briefmobile.com/cyanogen-demonstrates-quadrants-flaws