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)

iPad 備份的問題

老婆說她的 ipad 突然黑掉開不起來了, 送修後經 "強制開機" 後可以用. Apple 的人說, 拿回去備份完, 可以來換個新的 說到備份, 當然這工作落在我的頭上.不過根據過去的經驗,我好像不曾真正備份成功過.

首先是用 itune. 但 itune 備份了什麼呢? 從檔案 -> 裝置 -> 備份按下去, 沒多久就備完了. 如果選 "從備份回復", 它會說只能恢復設定之類的.如果選了"同步", 它會把照片同步到一個我找不到的地方,視訊倒是找得到, 就在 PC 的媒體櫃 -> 音樂 -> iTunes -> iTunes Media -> Home Videos. 別的網站上也說到, 可以把 iPad 當作外接硬碟, 把照片 copy 到 PC 裡, 不過它只能拷貝用相機拍下來照片, 卻看不到從網路下載的照片.更別說用 pages 寫的文件跑哪裡去了?

就在這個絕望的時候,Google 大神顯靈了. 我忽然找到一個叫 iTools 的軟體. 差別只在於 Google 時用 "iPad 備份 位置" 還是 "iPad 備份 軟體" 而已.這個 iTools 可厲害了, 不但 6,000 多張照片都找得到 – 3,000 張拍攝、3,000 張下載; 連電影、電子書、應用軟體和檔案也可以備份.

如果發現 iTools 不能連, 必須先將 iTune 斷線. 如果發現 iTune 不能連, 可以把碗豆莢, 金山手機助手, ….等等會占住 USB 的軟體先關掉. 照片多的話, 備份的時間很長. 真的可以先全部打勾, 睡一覺再起床驗收! 軟體的圖片就不抓了, 請參考 [ref 1].

軟體可以在這裡下載:

http://www.itools.cn/download

[ref]

1. 萬能的蘋果管理軟體iTools繁體中文版正式上線 輕鬆轉玩你的iPhone/iPad/iPod touch

DIAL 小註解

這邊的  DIAL 是指 Netflix 和 Youtube 最近在推的 DIscover And Launch 架構. 這個技術有什麼稀奇呢? 其實它是另一種把手機/平板的螢幕投影到電視大螢幕上的方法, 特別是那些支援 DIAL 的 APP 在兩個螢幕上都存在時. 雖然說我們已經有了 Wifi Display / Miracast, WIDI 可以投影任何手機或電腦畫面到電視上, 不過它們只能視為螢幕的切換,沒有動用到 TV 上的 APP.這點是主要的不同.

使用 Miracast 也不算是容易的事. 比方說, 原本手機和電視都是各自連到家中的無線 AP 上網, 但是為了要做 Miracast, 他們得要切到  的 1, 6, 11 CH 三者其中之一去進行連線.不然他們沒辦法互相發現對方. [1] 若是無線 AP 本來不是設在 1/6/11 CH, 那麼就得有從 AP 暫時斷線再連線的動作.

 

根據 Netflix 所做的比較, DIAL 可以提供簡單的連線方式 (見下圖)[2] – 假如我們先忘記有無線 AP.此處的假設是:第一個屏 (電視、機頂盒、藍光播放機的大屏) 已經有執行 APP 的能力, 而不只是一台 "非智慧型電視". 如果電視原本沒有 "智慧", 至少得接上一個轉接盒, 電視端才能具備連網、又能執行 APP 程式的條件.

那麼, 為何只要在第二個屏 (小屏) 上執行 Youtube、Netflix,就可以跳過電視上的設定, 直接播出畫面呢? 這裡面共有 3 個不同的角色 [3]. 大屏的平台提供者 (1st screen CE device deveoper), 它要能夠用正確的參數把大屏的 APP 程式跑起來,並且確保小屏的 APP 的 payload 可以送給大屏的 APP.而小屏的 APP 負責提供 payload,大屏的 APP 負責收 payload. 另外, 無論是大屏或小屏的 APP 都要先註冊 Application Name, 這樣才能確保不會把 Youtube 的內容送給 Netflix 的 APP 程式播.

根據網站上的評論 [4], DIAL 的規格是為了對抗 Apple Airplay 跨平台的優勢. 若是我 Android 手機上有個 Youtube, Android 電視端也有一個 Youtube APP, 兩者卻不能夠連動, 使用情境就不如 Apple 方便了. 然而 DIAL 只解決了連線, Miracast 只解決了 mirror; 要讓使用者完全從 "瞪小屏" 轉到大小通吃 – 例如: 讓大屏可以顯示小屏應有的操作 (如增加手機聯絡人), 而小屏本身又變身為遙控器,不顯示聯絡人編輯畫面, 這個還有賴於 "非蘋陣營" 軟體開發人員的努力.

[ref]

1. WI-FI Alliance Member Symposium 

2. DIAL

3. Details for Developers

4. The story behind DIAL: How Netflix and YouTube want to take on AirPlay

MHL 小註解

話說前幾天, 義大2:3輸兄弟的時候寫了 “DVFS 小註解", 這次是義大 6:7 輸統一, 只好來寫個 “CBUS" 轉移心情. 什麼是 CBUS (Communication BUS)呢? 它是 MHL (Mobile High-Definition Link) 裡面的新規格.MHL 的架構如下 [1].因為講到 CBUS 不可能不提 MHL, 所以標題也就順便改了.

實際上, MHL 若不是借了 HDMI 介面的平台, 恐怕也很難攻下一席之地.一個 MHL 的 source 端, 比方說: 手機, 有機會用 micro USB 裡面的 5 根 pin, 接到 HDMI sink 端的 7 根 pin (含 3 根 ground pin)來完成 MHL 的工作.由於 micro USB 和 HDMI 都是常用的介面, 因此 MHL 推廣起來應該省了不少力.它不但能夠把手機小螢幕送上電視這個大螢幕, 還順便解決了手機充電的問題, 真是一個聰明的設計. 

 TMDS (Transition-minimized differential signaling – 最小化傳輸差分訊號)主要用來傳送音視頻的資料. 在 HDMI 的規範中, 我們有 4 個 channel (通道) 可以用. 而在 MHL 裡面, [ref 2,3] 說它只有 3 個邏輯上的通道, 和一個實際上是 3 倍快的通道. 這樣一來, 高速公路比 HDMI 少了一個車道, 怎麼還是能支援到 1080@60P 和 8 聲道的 LPCM 音訊資料呢? 原來在 [1] 當中稱為 MHL 24 bits Mutiplexing, 但是在 MHL Packetpixel Multuplexing 裡面, 它還是 mux 4 個通道.

接下來看一下 VBUS. VBUS (Voltage Bus)負責供電, 在 MHL 2.0 的規格中, 它已經可以用 5V 供應 900mV 的電流. 如果只是純粹供電, 好像學問不大? 看了 Agilent 的資料 [4],需要測試的項目也包括了 VBUS 究竟是否會干擾到 CBUS (Coupling, crosstalk),以及另一端 – 遠端 (Far End)的 MHL 是否會干擾 CBUS 和 VBUS.

至於 CBUS , 顧名思義它是做通訊用的. 當 MHL 的接頭插上 sink 端的 HDMI 端, CBUS 的 1.8V 訊號下拉, 讓 sink 可以偵測到熱插拔 (hot plug). 由於 CBUS 對接到 HDMI 的 pin 19, 這根訊號本來就是做 hot plug detection 用的, 因此和 HDMI 完全相容.

除此之外, CBUS 也兼著從 sink 端讀出 EDID (Extended display identification data – 延伸顯示能力識別). 原本的 EDID 可以從額外的 I2C 介面或是 HDMI 的 DDC 通道 (Display Data Channe – HDMI pin15/DDC clock 和 pin 16/DDC data) 讀取的. 但 MHL 已經把這個訊號線精簡掉, 所以 MHL 只能從 CBUS 上獲取這些資料.同理, CEC (Consumer Electronics Control)也被歸併到 CBUS 上.

總結來說, MHL 做的事和 HDMI 幾乎差不多. 在 VBUS 和 TMDS 的部份, 軟體的人幾乎沒有什麼事情可以做,因此負責 MHL driver 等於負責 CBUS driver.

[ref]

1. New Multimedia Interface MHL: Market Status and Technology

2. Silicon Image提供可攜式產品高清連結(MHL™)技術

3. MHL简介及信号测试方法

4. MHL Test Solution Overview