分類: 技術

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

Pattern Insight 的妙用

Pattern Insight 是一個商業軟體, 用來保障 （不是保證）release 出去的 code, 不會有先前已經 fix 過的 bug.

它的原理也相當簡單, 拿一個基準點的 reversion (or commit) A, 對照一個 fix 過某個 bug 的 reversion B, 產生一個 patch 的 pattern. 然後在各個版本之間, 用這個 pattern 去 match 可能還沒有fix 此 bug 的 version (or branch), 將它high light 出來.

當然, 做為一個收錢的軟體, 諸如檔案改過名字之類的狀況, 也會考慮到. 這個軟體的精神大概就是這樣.

[試用版下載] 要填一些資料.

[Demo 影片]

Pattern Insight Clone Detection from Pattern Insight on Vimeo.

獅子來了！

蘋果的新作業系統 OS X 版, 代號 LION 的版本已經可以下載了.  花 29.99 USD 就可以把這頭 3.49GB 的肥獅請回家.

因為是用 WIFI 下載, 我午餐都吃完了還沒下載完~~

..

下載完開始安裝…

和 Windows 一樣,  升級 OS 後會有不相容的軟體出現. 不過帥的地方是我不需要的軟體正好因為不相容而被擋掉了. 當然, 如果我的 “大塚資訊" （卡巴斯基代理商）還沒賣就不會這麼瀟灑了.

安裝完 LION 之後, 其他地方似乎只有小小的改變 – 例如 launchpad 和 facetime 跑到桌面上. 但是…滑鼠和 touch pad 的滑動方向竟然和以前變得相反了. 想讓畫面往下移？無論是兩隻指頭往下滑, 或是滑鼠滾輪往後轉, 都會得到畫面往上的效果!!! 反之亦然！

進到系統偏好設定裡面一看, 原來這個 設定叫做 “自然". 哪裡自然啊？我已經習慣成自然 20 多年了, 怎麼會變成這樣呢？原來一切都是為了和 iPhone, iPAD 相容.  

在 iPAD 的世界, 想要內容往下, 手指就往下撥, 新的內容從下面落下來, 這樣挺直覺的. 不過在 NB 的世界, 我要內容往下走, 才會往下撥, scroll bar 也是往下啦啊！現在蘋果硬是把兩種方式統一了, 我真是…無言.

No! 我有話要說, 現在我可以體諒歌星比莉了. 她說要電梯下來, 所以上樓時會按下, 而不是按上. 可見得比莉姐其實是台灣的 “假" 柏斯, 她真是被埋沒了~~~


 

 [後記]

赫然發現  Parallel 5.0 和 Lion 不相容, 只好又花錢去買 Parallel 6.0 升級版. 希望沒有別的東西不相容了. 建議買升級版 39.99 USD 的升級程式 , 頂多加上15 USD 的 6 個月免費升級權利. 如果獅子上市超過 3 個月, 應該就不用擔心 Parallel 和 Lion 有什麼過節了. 不過獅子才剛剛出柙, 我比較偏保守一點.

2011/9/7

買了免費升級權利後, 昨天收到通知可以免費升到 Parallel 7.0 版. 主要的改進是速度變快了.

[睡獅醒了]

原來超慢的獅子在更新父親節版本後, 反應速度確實有所提昇.  不過, 還沒安裝的人可以再觀望一下.

2011/9/7

先前遇到獅子很慢的狀況, 連中文打字都有問題. 經查證主要原因是硬碟有壞軌. 好像獅子用的暫存硬碟比較大, 所以遇到壞軌就會慢到不行. 忍痛換了一顆硬碟之後, 速度就可以了.

 

NPTL 小註解

NPTL 的意思是 "Native POSIX Thread Libray". 話說 Linux 裡面的 thread 原本不是真的 thread, 而是 process 偽裝而成的, 它們被稱為 Linux thread. 基本上, 原來的 Linux thread 被拷貝成多份, 每一份都使用同樣的定址空間, 於是乎可以達到近似於 thread 的效果.

不過畢竟它並不是真正的 thread, 所以若是信號送給其中的一個 Linux thread, 結果這個 Linux thread (實則為 process) 恰好被 block 住了, 那麼這個信號就永遠無法被其他的 Linux thread 收到. 比方說 kill() 很可能就無法把所有的 Linux thread 殺死, 而是有些死了, 有些變成殭屍.

在使用 GDB debug 的時候, 也只能針對某個 Linux thread 做控制,  而不能輕易地用 stop 一個 process ID, 就停止它底下所有的 thread.

為了解決 Linux thread 的問題, Red Hat 提供的 solution 就是 NPTL. NPTL 不需要一個額外的化妝師 （管理線程 – manager thread) 將 process 化妝成 thread. 也不需要在終止所有 Linux thread 之後才能回收它們所使用的記憶體.

相對地, 原本的 Linux thread 相當擅長 process 與 process 之間的同步, 畢竟大家內在都還是 process. 於是 NPTL 也多出了一個機制來增加 process 等級之間的同步. 這個機制就是 futex (fast userspace "mutex).

在 Linux 下編譯的代碼, 可以選擇支援 NPTL 或是 Linux Thread 的 glibc 版本來編譯. NPTL 基本上優於 Linux thread, 但兩者都堪用.

[ref]

1. Linux programmer's manual: futex

2. Linux 线程模型的比较：LinuxThreads 和 NPTL