分類: 技術

好的和壞的 Multi-path

以我們電信系的專業來說, multi-path （多重路徑）是不好的. 它意味著一個訊號, 分別走了很多不同的路徑,才到達接收端.在同一個環境中, 因為訊號路徑的不同,有的訊號先到, 有的晚到. 雖然大家都是 "對的", 不過路徑比較長的那一組訊號通常會比較弱, 弱的訊號又會干擾強的那組.假如我的訊號一秒鐘才變一次,那麼 multi-path 對我們幾乎沒啥影響.好比搭高鐵或是自強號從台北到高雄, 假如要求 6 小時之內到達, 訊號都能夠鎖定. 假如要求 3 小時要到, 搭自強號的訊號和搭第二班高鐵的人差不多時間到, 他就變成干擾源了.

通訊上為了消除 muti-path, 有各種不同的手法. 例如用多根天線來定位真正的主要訊號來源. 好比我在台南多設一個檢查站, 我就可以依時間差推算出誰是搭自強號, 誰搭高鐵? 當然, 我會希望找到搭高鐵的人, 因為他還精神奕奕, 訊號比較強, 也比較不容易變成速度上的瓶頸. 萬一我改成兩個小時就要到, 當然更不想要慢到的人來搗亂.

有趣的是, 這個電信上的名詞, 到了網路通訊竟然大變調.　網路通訊裡的 multi-path, 變成個好東西了. IPMP (IP Network Multipathing) 裡面的多重路徑就是備援路徑的意思. 假如我有兩張網路卡 – 當然就有兩個 MAC address, 假設其中一張卡突然被拔掉了,我希望原來屬於這張卡的 IP address 能夠無痛地轉移到另外一張網卡上面去, 這就是 IPMP 的精神.雖然是 "無痛", 那麼 IP address 是不變的, 但 MAC address 還是會變.

根據 [ref 1] 的描述, 我要對兩張網卡各自設一個正常的 IP, 和一個備援的 IP. 備援的 IP 因為有 deprecated (棄用) 的屬性, 表示它是測試專用的, 不會拿來對外使用.另外它還要有一個屬性是 -failover, 表示這個 IP 會做 fail detection. 當網卡發生問題後,測試 IP 會發現正常 IP 已經不通了. 此時系統會去 /etc 下的 hotname.xxx 裡面去查,哪一張網卡和壞掉的網卡屬於同一個 group. 然後把壞掉的 MAC address 的正常 IP 指定給同 group 中正常的 MAC address.

那麼正常的 MAC address 不就會有兩個 IP 了嗎? 此事要靠邏輯介面來解決. 雖然好的網卡只有一個實體, 此時它會模擬出 3 個邏輯介面. 標準的邏輯介面給自己正常的 IP 用, 衍生邏輯介面 1 給自己的備援 IP 用, 衍生邏輯介面 2 給受難的 IP 用. 當壞掉的卡的網線重新插回來的話, IP 也會回到自己原來的 MAC address. 

上面介紹的觀念屬於有兩張網卡的例子, 實際上, IPMP 還可以延伸到 [2]:

A. Link-Based IPMP with a Single Interface

B. IPMP with Multiple Interfaces

1. ACTIVE-STANDBY

a) 2 NICs, 1 IP (Link-Based)

b) 2 NICs + 1 Logical IF, 2 IP (Probe-Based)

c) 2 NICs + 1 Logical IF and 3 IPs (Probe-Based) – Classical Solaris  Active/Standby IPMP 

2.  Active-ACTIVE IPMP

a) 2 NICs, 1 IP (Link-Based)

b)2 NICs + Logical IF, 2 IP (Probe-Based)

c)2 NICs + 1 Logical IF and 3 IPs (Probe-Based) – Classical Solaris Active/Active IPMP

d)3 NICs + 1 IP (Link-Based)

前面介紹的那一種, 算是 ACTIVE-ACTIVE 的 2 NICs + 1 logical IF + 3 個 IPs. 只有一張網卡的時候, 符合 case A. 此時依然把這張網卡加到 group, 只是多賦予它 failover 的特性 [3] . 那 link-based 又和 probe-based 有何不同呢? Link-based 最基本的保護, [ref 2] 說它 always on. 倒是 probe-based 的偵測需要設定檢查的時間, 例如 FAILURE_DETECTION_TIME = 10 秒,這樣 in.mpathd daemon 才能每隔 10 秒送 ICMP (Internet Control Message Protocol) echo 去檢查一下網路.這看起來很有學問的 ICMP echo, 呃, 其實只會需要用到 request ping (type = 8) 和 reply ping (type = 0) 吧!

[REF]

1. Solaris10 – IP Network Multipathing (IPMP)

2. IPMP, Bonding, Link Aggregation, vLAN Tagging on Solaris, Linux, HP-UX and IBM AIX

3. How to Configure a Single Interface IPMP Group

Apple Air 更換 SSD 硬碟小筆記

前幾天到大陸出差,就在出發前筆電變得怪怪的- 非常地慢,好像哪不對勁.本來這個問題也不難解決, 上次就是直接買一顆新硬碟來重灌. 不過這次馬上就要出差, 似乎沒那麼多時間可以把這些事情做完, 只好把笨重的 Apple 的 Time machine 大硬碟也 hand carry 到大陸去施工.

沒想到真正有問題的應該是 time machine, 被它重灌過以後, 我三歲的 macbook pro 就不會動了. 一開始 time machine 還能 copy 出一點東西, 所以我勉強拷貝了兩個重要的資料夾出來.最後它就完全罷工,連磁碟工具也修復不了.這給了我一個啟示,time machine 如果怪怪的, 一定要趕快備份, 愈拖愈危險!

因此第一天上工只能靠手機回 mail, 到了第二天午餐時間, 我就冒雨衝到北京的五道口購物中心買了一台 13″ Apple Air 回來.什麼規格都還沒摸清楚, 反正就刷卡買了號稱可以 12 小時不充電的. 在大陸蘋果店買東西不算貴, 但是刷 “外卡" (外國卡?) 要加 3% 手續費,這樣一來就貴了不少! 回到客戶公司用了之後,發現我這型號比較低規. 記憶體少只有 4GB.測試了一下, 其實基本夠用.不過還是手癢把 swapfile 設到 SD 卡上.

sudo launchctl unload /Library/LaunchDaemons/dynamic_dns_updater.plist

sudo vi dynamic_dns_updater.plist

把最後的 private/var/vm 改為 /Volumes/32GB/vm

sudo launchctl load /Library/LaunchDaemons/dynamic_dns_updater.plist 

試過不重新開機真的可以用, 但重新開機後就不行了, 還不知道為什麼? 推測是 SD card driver 比 sleepimage 還要挽起來的關係.

至於內建硬碟不但小 (128GB),而且和一般 SSD 規格不相容, 使我原本的 1TB SSD 毫無用武之地,必須要另外買特殊規格的 SSD 卡, 以及梅花形的螺絲起子.今天買的東西都送來了, 於是開始施工.首先拿出在露天拍賣買的五星 (更像是梅花) 螺絲起子! 一開始起子滑牙拆不下螺絲, 還以為自己買錯了? 看到另外一個賣家的圖片才領悟到我應該要換 1.2mm 那頭.Apple 真的相當狡猾, 螺絲是用梅花形的, 乍看之下很像是被轉壞掉一樣.

ddd  

用對工具之後, Air 的後蓋就輕鬆地被拆下來了! 我買的 200 工具組還附了一個撬棒,讓我們把 SSD 挖起來.這 SSD 的上方全部都是電池, 難怪可以號稱用 12 小時.

aaa

兩隻 SSD 排排站.原本的顆粒是 SanDisk 的, 控制 IC 是 Marvell 的. 新買的 SSD, 控制晶片和顆粒都是 Samsung 的.Apple Air 13 年式的 SSD 和 13 年上半年以前的形式不相容, 比較短一點.這點我有注意到, 要是買錯就悲劇了. 基本上 768 GB 和 1TB 的 SSD 都只有 12 年式的 Apple Air 才適用, 13 年式的最大也看到 512 GB.

kkk

換了 SSD 之後, Apple Air 就被視為一台新的電腦.此時可以從 (新的) time machine 中把以前的環境都還原回來.

不過悲慘的部分是 Office 又要啟動一次. 我很不想讓微軟賺我兩次錢. 除了等到上班日打電話到微軟客服中心電話啟動之外,我也再調校一下系統字形吧! 有好幾天都有人說我寄的信變亂碼, 這在我第一用 Macbook Pro 的時候也發生過, 當時是用安裝新細明字形解決的, 最近微軟似乎不給下載新細明字形了,趁這個假期好好研究一下!

對了! 有人說為何不一次就攻頂買大容量的 Air 呢? 實在是因為它只有 128GB 和 256GB 兩款有現貨. 如果要買 512GB 的, 至少要等 3~5 天. 稍微拖一下我就回台灣了, 沒有必要等客製的版本. 再說, 一如我不想讓微軟賺我的軟體錢那樣, 我也不喜歡讓蘋果賺我的硬體錢.自己在淘寶買的 SSD  比蘋果賣的便宜不少!

只有個小東西非買蘋果出的不可,那就是我本來有兩隻 MBP 用的 MagSafe 變壓器, Apple Air 改用了 MagSafe 2,所以要多買個轉接頭,讓原本的變壓器延續它的生命! 

ccc

DivX 專利小整理

DivX 有哪些專利呢? 到 USPTO 找了一下, 一共有 14 篇, 其中有兩篇是延伸自他們先前的專利.

專利字號 專利名稱 極簡摘要 生效日
8,510,303 Singular, collective and automated creation of a media guide for online content 可以對 user 觀看的內如打 tag, 然後送特定資料給 user. i.e. push 廣告之類的. 2013/8/13
8,472,792 Multimedia distribution system 一個多媒體檔案中有兩種 index, 第一種指到 video frame, 第二種指到一群 video frame. i.e. 做 trick play. 2013/6/25
8,301,793 Chunk header incorporating binary flags and correlated variable-length fields 一個多媒體播放系統, 檔案中有 pointer 指到下一塊 data 的位置, 使得檔案能夠依不同的方式播放, 而不會讓檔案大小明顯增加. 2012/10/30
8,289,338 Systems and methods for font file optimization for multimedia files 檔案系統中的字形檔 (font file) i.e. 字幕等等的儲存方式 2012/19/16
8,233,768 Hierarchical and reduced index structures for multimedia files 用 index 技巧保護 content 2012/7/31
8,201,264 Federated digital rights management scheme including trusted systems 聯邦式的 DRM 保護, 延伸 7,515,710 2012/6/12
8,139,651 Video deblocking filter deblock filter, 延伸 7,886,069 2013/3/20
7,886,069 Video distribution system including progressive playback 根據 user 的指令更新遠端的媒體播放內容 2011/2/8
7,729,426 Video deblocking filter deblock filter 2010/6/1
7,664,872 Media transfer protocol 從 server 到 CE device, 根據特性使用不同的 data rtae 傳輸 2010/2/16
7,519,274 File format for multiple track digital data 多個 track 的檔案格式 2009/4/14
7,515,710 Federated digital rights management scheme including trusted systems 聯邦式的 DRM 保護 2009/4/7

7,460,668

Optimized secure media playback control 不用連到外部電腦就能註冊的的播放控制系統. 2008/12/2
7,295,673 Method and system for securing compressed digital video 加密某些 video frame, 但不用加密 reference  到加密 frame 的 frame, 2007/11/13

雖然大家對於 DivX 的認知是一個 video format, 或是一個有 DRM 保護的片商. 但是它主要的專利在於檔案格式, DRM, 以及 de-blocking. 真正和 video 播放有關的專利, 倒是付之闕如. 最有趣的是, 在專利  7,519,274 當中, 它以具體實施例偷渡了這麼幾段話:

DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS 

In accordance with the present invention, the version of the video codec used in AVI files is signaled by the FourCC code in the fccHandler field or member of the AVISTREAMHEADER of the corresponding stream header `strh` chunks, and the FourCC code bicompression field or member in the BITMAPINFOHEADER of the corresponding `strf` chunks. 

By way of example, for videos encoded according to a codec developed by DivX Networks, Inc., 10350 Science Center Drive, Building 14, Suite 140, San Diego, Calif. 92121, the FourCC codes fccHandler in the stream header (`strh`) of the AVISTREAMHEADER is set to "divx" or "DIVX". Furthermore, the FourCC (DWORD) code biCompression in the BITMAPINFOHEADER of the corresponding `strf` chunks is set to signify the detailed codec version. 

Specifically by way of example, for version DivX 3.11, `div3` or `div4` is used in AVISTREAMHEADER, and `div3` or `div4` is used in BITMAPINFOHEADER; for version DivX 4.x, `divx` is used in AVISTREAMHEADER, and `divx` is used in BITMAPINFOHEADER; and for version DivX 5.x, `divx` is used in AVISTREAMHEADER, and `dx50` is used in BITMAPINFOHEADER. 

By now it should be appreciated that a file format for storing digital data with a high compression rate has been described. A file format in accordance with the present invention is compatible with high level data compressing algorithms, such as MPEG-4. Its data compression ratio is about six to ten times higher than a standard DVD format. In accordance with the present invention, the file format is capable of storing data in multiple streams or tracks. The file format is also able to encode and archive video, audio, and text data on easily accessible streams or tracks. Furthermore, the file format is able to provide protection of the copyright of the digitized content. 

While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific form or forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention. The present invention is limited only by the claims that follow. 

儘管 DivX 努力在不具備專利效力的章節裡面幫自己打廣告, 重申 DivX encoder 的優點,還是難掩它沒有主流 encoder 專利的缺憾.畢竟 encoder 做得再好, 還是要和 decoder 相容. 就以 7,519,274 這個專利來說,它只能在檔案格式上做文章.雖然專利名稱有 multi track, 但申請專利的人並沒有忘記把一個 track 的狀況包括進去.以他們的第一條 claim 來說.

1. A playback device configured to play data encoded in a multimedia file, comprising: a processor configured to read the multimedia file; wherein the multimedia file has at least one video track and includes a video stream descriptor list comprising: a video stream header chunk; a video stream format chunk following said video stream header chunk; and a video stream name chunk including a string indicating a video stream in said at least one video track; said video stream descriptor list further comprising a video stream header data chunk in response to said at least one video track being a digital rights management (DRM) protected video, said video stream header data chunk following said video stream format chunk in said video stream descriptor list; said video stream header data chunk in said video stream descriptor list including a DRM information data block comprising: a first member specifying a version of the DRM; and a second member specifying a protection of the DRM said DRM information data block in said video stream header data chunk having a data structure defined as: TABLE-US-00020 typedef _DRMinfo { WORD wVersion; STR sDRMinfo; } DRMINFO. 

看了雖然很眼花, 但簡單講就是: 多媒體檔案在 video stream descriptor 裡面有至少一個 video track, track 裡面有 video stream descriptor. 其中又有 video stream header chunk, format chunk, name chunk, data chunk, format chunk. 在 data chunk 裡面有 DRM revision 和 DRM information data chunk.

以我的認知是, 如果只有一個 track, 而且不受 DRM 保護, 就不受這一條的限制 – 因為那樣把所有傳統的檔案都包括進去了.為了防堵那些不用 track 為單位的檔案, 本專利在 claim 42 強調包含 multiple chapter. 而 claim 43 涵蓋只有一個 chapter, 但是有多個 data chunk 的狀況. claim 45 規範有 subtitle 檔案, claim 46 則規範有 subtitle, 但分成多個 data chunk 的狀況. claim 48 又把前述的 subtile 狀況, 加上有 DRM 時的例子…, 目標很顯然就是想一網打盡, 能想的都想了…從這個角度來看, 還真是滿厲害的.

 

在 Android 底下使用 CGROUP

CGROUP 是什麼呢？在 WIKI [1] 裡面簡直沒有幾行字, 要看懂不容易. 簡單地說, Linux 裡面有很多 process, 我們為了分而治之, 所以增加 group 的虛擬觀念. 每個 group 的 process 能夠使用的資源會有不同的限制. 比方說, 某些 process 可以用雙核, 某些 process 只能用單核. 某些 process 可以用 2GB DDR, 另一些 process 只能用 128MB.

我們可以在 console 下面 cat /proc/cgroups. 就會看見, 有 cpuset, cpu, cpuacct, memory, device, freezer, blkio, net_prio 等幾個 subsys_name. 而且他們各自有 hierachy, cgroups 的數目, 以及 enable 與否. 因為 Linux 底下的排版跑掉了, 所以除了第一列, 其他每一列都縮排.

android cgroup

以上面的 Android 系統為例 (Android 底下也是 Linux), 其中 cpuacct 這個 subsystem 就有 48 個 cgroup 之多. 什麼是 cpuacct 呢？它是指 CPU accouting control [2].  假如 Linux 沒有生成 cpuacct 這個 cgroup, 我們可以用 command line 產生.

mount -t cgroup -ocpuacct none /sys/fs/cgroup/cpuacct

我用原生的 Linux 3.10 只看得到 memory 在 cgroup 的目錄下. 使用上面這個 mount 指令後, 我們可以在 /sys/fs/cgroup 底下看見 cpuacct. 如果這個 cgroup 已經成立, 我們就可以看到一些統計資料, 例如 cpuacct.stat, cpuacct.usage, cpuacct.usage_percpu…等等. [Note 1]

cat /sys/fs/cgroup/cpuacct.stat 可以看到 user 和 system 各自用了多少 cpu 時間, 例如:

user 100352

system 79817 (單位是 user_hz [3])

cat /sys/fs/cgroup/cpuact.usuage 得到

2096699156712 (單位是 ns)

cat /sys/fs/cgroup/cpuacct.usage_percpu 得到兩顆 CPU 的數字

1145393229564    952319269088

兩者相加就是 cpuacct.usage, 不過不是同一個時間, 所以數字又變大了. 光看統計數字沒有太大的幫助, 我們要怎麼使喚它呢？根據 [REF 4] 的說法, 至少有三種方法可以做到. 其中 command line 和 libcgroup 的方法都被它介紹過了, 還有一個 LXC 的方法, 在 [REF 5] 當中有說明.

我這邊就只整理 command line 的方法, 因為它最容易了解 cgroup 目錄階層的意義.我們可以手動在 /sys/fs/cgroup 底下操作.

[CASE 1] 如果要限制的是可以用幾核的 CPU, 比方說雙核中, 誰可以用兩顆 CPU, 誰只能用 (某) 一顆, 那麼要先設定第一核與第二核的定義.

cd /sys/fs/cgroup/cpuset

sudo mkdir first_core

echo 0 > /sys/fs/cgroup/cpuset/first_core/cpuset.cpus

sudo mkdir second_core

echo 1 > /sys/fs/cgroup/cpuset/second_core/cpuset.cpus

接下來開始分配, 假設有兩個 process, pid 分別為 1185 和 1195.

echo 1185 > /sys/fs/cgroup/cpuset/first_core/tasks

echo 1195 >/sys/fs/cgroup/cpuset/first_core/tasks

echo 1195 >/sys/fs/cgroup/cpuset/second_core/tasks

結果使得 pid 1195 可以用雙核, 而 1185 只能用單核.

[CASE 2] 若是要進一步把 pid 1185 的使用權種降得更低, 我們就要定義出比重. 

cd /sys/fs/cgroup/cpu

sudo mkdir high

echo 2048 > /sys/fs/cgroup/cpu/high/cpu.shares

sudo mkdir low

echo 512 > /sys/fs/cgroup/cpu/low/cpu.shares

此時高低權重就出來, 接下來同樣是把 pid 加入 task 當中.
echo 1185 > /sys/fs/cgroup/cpu/low/tasks

echo 1195 > /sys/fs/cgroup/cpu/high/tasks

這樣在同一顆 CPU 中, 1195 也可以拿到 1185 四倍的 CPU 時間.

[CASE 3] 如果要分配記憶體的用量, 首先要設一個會限制記憶體的 group, 例如 limited_memory.

cd /sys/fs/cgroup/memory

sudo mkdir limited_memory

將它的記憶體上限定為 128M Bytes

echo 128000000 > /sys/fs/cgroup/memory/limited_memory/memory.limit_in_bytes

然後江這個 pid 加到這個 group

echo 1185 > /sys/fs/cgroup/memory/limited_memory/tasks

如果它的記憶體用量硬是超過限制, 它會 swap 到 disk, 不會用 DDR. 不過看來這樣也會拖累效率就是了.

[ref]

1. 中文版 WIKI

cgroups(控制組)是Linux核心的一個功能，用來限制報告和分離一個行程組的資源(CPU、記憶體、磁碟輸入輸出等)。這個工作是由Google的工程師(主要是Paul Menage和Rohit Seth)在2006年以「process containers(行程容器)」的名字開始的；[1] 在2007年的晚些時候被重新命名為控制組(由於在核心中「容器」這個名詞的歧義引起的混亂)並被合併到2.6.24版的核心中去。[2] 自那以後，又添加了很多功能和控制器。

cgroups的一個設計標的是為不同的應用情況提供統一的介面，從控制單一行程(像nice)到系統級虛擬化(像opeNVZ，Linux-VServer，LXC)。cgroups提供：

  • 資源限制：組可以被設定不超過設定的記憶體限制；這也包括虛擬記憶體。[3] 原來的分頁機制是在Linux研討會的Containers: Challenges with the memory resource controller and its performance報告中提出的。[4]
  • 優先化：一些組可能會得到大量的CPU[5] 或磁碟輸入輸出通量。[6]
  • 報告：用來衡量系統確實把多少資源用到適合的目的上。[7]
  • 分離：為組分離名稱空間，這樣一個組不會看到另一個組的行程、網路連線和檔案。[2]
  • 控制：凍結組或檢查點和重新開機動。[7]

2.  CPU Accounting Controller

3. 3.3. cpuacct

4. Linux Control Group 介紹

5.  lxc 建立和設定虛擬機器

[Note 1] 同理, 我也可以 mount -t cgroup -ocpuset none /sys/fs/cgroup/cpuset, 不過需要手動在 cgroup 底下建這些目錄才 mount 得到. 我用 Linux 3.10, 最初 cgroup 底下只有 memory 一個目錄而已.

建完新目錄之後, 底下就會自動繼承出一大堆子目錄. 例如 cpuset 底下的 first_core 就會自動有 cpuset.cpus.

YUV 格式小整理

最近在討論 video 的格式, 順便整理一下表格.紅色是 Android 支援的.

420 簡單系列 
Type Luma  chroma   Planar or not Note
I420 YYYYYYYY UU VV Planar = 3 plane
J420 YYYYYYYY UU VV Planar = 3 plane,
範圍 0-255
YV12 YYYYYYYY VV UU Planar = 3 plane
NV12 YYYYYYYY UV UV Semi-Planar = 2 plane, Y + UV
NV21 YYYYYYYY VU VU Semi-Planar = 2 plane, Y + UV
420 變化系列
Type 採樣方式 Note
YUYV Y0U0Y1V0 Y2U2Y3V2 Y4U4Y5V4 … =YUY2=V422=YUNV
YVYU Y0V0Y1U0 Y2V2Y3U2 Y4V4Y5U4 …  
UYVY U0Y0V0Y1 U2Y2V2Y3 U4Y4V4Y5 … =Y422=UYNV
Y211 YXYXYXYX UXXXVXXX Y422 的一半,X 表示沒取樣
422 系列
Type Luma Chroma   Planar or not Note
I422 YYYYYYYY UUUU VVVV Planar = 3 plane
J422 YYYYYYYY UUUU VVVV Planar = 3 plane,
範圍 0-255
NV16 YYYYYYYY UVUVUVUV     = 2 plane, Y + UV
NV61 YYYYYYYY VUVUVUVU = 2 plane, Y + UV

[ref]

1. YUV 格式說明

2. YUV

3. YUV

4. 关于yuv 格式-Semi Planar和Planar

5. Pixel and Planar Image Formats

6. V4L2_PIX_FMT_NV16 ('NV16'), V4L2_PIX_FMT_NV61 ('NV61')