Freedce

今天安裝好 freedce, 並且跑了一下 rpcd, echo_server, echo_client, 已經確定可以用了.

接下來, 應該是多點接入的問題.

真的要 coding 之前, 可能得多看看相關的 API 說明.

別忘了收集到的資料 放在 kunsheng.chen@gmail.com 資料收集 DCE RPC 的 E-MAIL 內.

車機 download issue

之前討論到在 harddisk 上產生一個隱藏性的磁區串列, 然後將資料放到這個磁區, 不要再更動 FAT/DIR.

也許可以試試 預先產生一個很大的檔案, 然後將 自我解壓縮檔 overlap 在這個檔案開頭 (i.e. 覆蓋但不 truncate). 也許比較好做. (及測試).

經過在 XP 上的測試, 發現 info-zip 的 unzipsfx 應該可以達到這個目標. 很好. 只差在 XDOS 上再測一遍了.

DCE/RPC

Alcatel-Lucent 的 RTB interface 竟然是使用 DCE/RPC.

找了一堆東西, 發現 python 並沒有 支持 DCE/RPC. (但是有 ONC/RPC), 這可是麻煩了.

試著 google 'DCE/RPC +SOURCE', 找到了 www.opengroup.org, 在 非商務應用的前提下, 是 LGPL 的 License. 試著去用一下. 先了解是否可以滿足這個應用.

接著 google '"DCE/RPC" +linux', 找到 freedce.sf.net 這個網站. 似乎是將 public domain 的 dce/rpc port 到 linux. 試一下.

另外有一篇文章值得參考 http://www.linuxjournal.com/article/2204 , 有列一些 reference.

SIP/ISC - 3

繼續閱讀, 並翻閱相關的 source.

原來 ser 的 parser 是用到那裡就 parse 到那裡. 而且大量使用 convert string to lower case then treate 4 octets as unsigned long inter to speed up the comparision.

有趣.

apache +mod_python +PyGreSQL 突然跑不起來

今天打算把 http://nb27/bcf/ 重新跑起來, 結果竟然失敗, 出現

PythonHandler mod_python.publisher: ImportError: libpq.so.4: failed to map segment from shared object: Permission denied

試著重裝一下 PostgreSQL 8.1.4, PyGreSQL, mod_python, 結果都不行.

google 了一下, 發現原來也有人遇到類似的問題. 原因是 selinux 不允許 apache 使用該目錄下的內容.

是需要執行

# cd /usr/local/pgsql
# chcon -R system_u:object_r:httpd_modules_t lib/

這是跟 selinux 相關的 設定, 但不知道是什麼原因造成這個問題.

也許是因為我執行過

# cd /usr/local
# mv pgsql pgsql-8.2.3-9-42
# ln -s pgsql-8.1.4 pgsql

SIP/ISC - 2

繼續閱讀
SER - Getting Started 5 - 6.

http://www.tech-invite.com/ - 繼續看這個網站, 真是很棒.
例如: 講到 call flow, 他會有圖示; 講到 SIP 的各個欄位, 會用 ABNF 語法來表示, 還會列出相關的 rfc 出處. 真的是很棒的網站, 應該要 mirror 下來.

SIP/ISC

今天搜尋進一步的相關資料. 記下來免得忘了.

http://www.iptel.org/files/sip_tutorial.pdf 中有一章節, 介紹 SIP 在 IMS 的環境.

http://www.onsip.org/ 是一個不錯的入口網站,
http://www.internet2.edu/sip.edu/

http://www.tech-invite.com/ - a Portal devoted to SIP and surrounding technologies
最大的優點是, 對於相關的資訊都有整理過, 不是光 SIP Protocol 本身, 與 IMS/PSTN 相關得東西都有涉獵.

閱讀:
1. 比較 ser 及 openser 的文章. - (還是 用 ser 好了. 但別忘了 openser 有 Cisco 的產品所採用)
2. SER - Getting Started 1 - 4.

PostgreSQL 的測試

繼續之前的測試,

測試環境及結果:

	pc26	nb27			pc34
OS	2.6.9-34.EL	2.6.9-34 .ELsmp	2.6.9-34 .ELsmp	2.6.9-42.0 .10.ELsmp	2.6.20-rc6 #1 SMP	2.6.20-rc6 #1 SMP	2.6.9-42.0 .10.ELsmp
python	2.3.4	2.3.4			2.3.4
PostgreSQL	8.1.8	8.1.4	8.2.3	8.2.3	8.1.8	8.2.3	8.2.3
PyGresSQL	3.8.1	3.8.1			3.8.1
CPU	Intel(R) Pentium(R) 4 CPU 2.80GHz 512 KB Cache (5605.85)	Genuine Intel(R) CPU T2400 @ 1.83GHz 2048 KB Cache (1998.36) (DualCore)			Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz 4096 KB Cache (4819.82) (DualCore)
RAM	1GB	1GB			2GB
duration	5:32:36 (22:39:05 - 04:11:41)	2:28:11 (16:33:14 - 19:01:25)	2:08:56 (15:11:55 - 17:20:51)	2:30:14 (17:47:33 - 20:17:48)	4:20:45 (22:40:28 - 03:01:13)	3:51:15	1:40:30
average dur./call	19.956ms	8.891ms	7.737ms	9.015ms	15.605ms	13.876ms	6.030ms
min dur. /1000call	11.29sec	7.23sec	7.19sec	7.19sec	4.54sec	4.54sec	5.26sec
max dur. /1000call	57.45sec	20.25sec	17.72sec	17.72sec	33.39sec	36.68sec	9.96sec
mean /1000call	19.956sec	8.891sec	7.737sec	9.015sec	15.605sec	13.876sec	6.030sec
std devi. /1000call	8.35sec	2.58sec	0.76sec	0.31sec	6.22sec	6.42sec	0.91sec

有趣的是, 對 nb27 而言, 更換到最新的 kernel 並不會讓執行速度加快.
也許應該在 pc34 上再試試這個條件.

另外, noatime 這個 mount 選項也可以試試, 看看可以有多少改善.

PostgreSQL 的測試

因為 S 廠商的需求, 做了一些關於 Radius/PostgreSQL 的測試.

測試程式:
1. rtls.py - 將預先產生的 1,000,000 筆記錄以 radius 的方式送出.
(每一筆記錄會產生 3 個 radius packets, 分別是 ringing, answer, release)
(收到 rad.py 的 ack 後才會送下一個 radisu packet)
2. rad.py - 將收到的 radius 資料轉發給 rtbsvr.py, 並回 radius 的 ack 給 rtls.py.
(只有 release packet 中的資料會轉發)
3. rtbsvr.py - 將收到的資料加入資料庫中.
以上程式, 都只跑在同一台機器. (與網路 stack 無關)

測試環境及結果:

	pc26	nb27	pc34
OS	2.6.9-34.EL	2.6.9-34.ELsmp	2.6.20-rc6 #1 SMP
python	2.3.4	2.3.4	2.3.4
postgresql	8.1.8	8.1.4	8.1.8
pygresql	3.8.1	3.8.1	3.8.1
cpu	Intel(R) Pentium(R) 4 CPU 2.80GHz 512 KB Cache (5605.85)	Genuine Intel(R) CPU T2400 @ 1.83GHz 2048 KB Cache (1998.36) (DualCore)	Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz 4096 KB Cache (4819.82) (DualCore)
memory	1GB	1GB	2GB
duration	5:32:36 (22:39:05 - 04:11:41)	2:28:11 (16:33:14 - 19:01:25)	4:20:45 (22:40:28 - 03:01:13)
handling average/call	19.956 ms	8.891 ms	15.605 ms
1000筆的 min dur.	11.29 sec	7.23 sec	4.54 sec
1000筆的 max dur.	57.45 sec	20.25 sec	33.39 sec
1000筆的 mean	19.956 sec	8.891 sec	15.605 sec
1000筆的 std var.	8.35 sec	2.58 sec	6.22 sec

軟體上的不同點 (下次測試時可以調整的):
1. postgresql 版本. 應該都調到 8.1.8 或 8.2.*
2. OS 版本. 應該都用 2.6.9-34.ELsmp. (但 pc34 是 修明的工作 設備, 舊版沒有 對應的 driver) 或都採用 2.6.20 系列.

閱讀 javascript 相關資料

今天試了一些東西得記下來
1. window.onbeforeunload event handler.
例:
window.onbeoreunload = function() { if (modified) return "something need to save"; };

如果 modified 為真, 則在準備離開當前頁面時 (含關閉視窗 或 分頁), browser 會提示 一些制式訊息, 及 onbeforeunload 所傳回的字串.
果選擇確認, 就會離開或關閉. 選擇取消 則會停留在原頁面.

2. 閱讀完 JavaScript 的 Operator, JavaScript Functions.
例如: === 是表示 型態 和 值 都要相等., !== 表示 型態 或 值 不等.
Function, Function.prototype, arguments, arguments.callee, arguments.caller 等.

3. 閱讀了 prototype 中的 base.js. 理解一些應注意事項.

download over air for terminal feature

今天又跟 Jason 通了電話, 看樣子 download 還是得做. spiparm.dat/parm.dat 也逃不了.
parm.dat/spiparm.dat 是還好啦. download 的話就有蠻多問題的.

雖然可以將部份連續的 sectors 保留下來做這個用途, 但總是有問題.
我大概的想法是
留下兩個 cluster 是用於索引的. (我還是不確定這兩個 blocks 是否有可能會被同一個 erase/write cycle 所影響到,.... 沒有資料啊.....)
下載時, 就同步更新這兩個索引. 如果 資料寫到一半故障, 索引是舊的, 就不會有問題.
如果更新第一份索引時故障, 第二份(還是舊的) 就可以用. 如果是第二份故障, 那就算了.
這樣就可以 tracking 可能的寫入位置.

但在 copy 到 drive C 時, 還是可能出問題......
這時就要讓 drive A 的程式可以 format drive C 才行. (怎麼知道 drive C 故障了 ?)

一堆問題.... 還是得想....

Zipit, Zipit, Zipit !

今天同事根據 Internet 上的資料, 焊好 Zipit 上的 debug console, 再把 相關的檔案 flash 到 Zipit 之後, 開機, 然後成功 ~

當然, 事情並不是這麼順啦, 首先是 debug console 相關焊點並不都是這麼好焊. 光是找那個焊點, 就蠻花眼力的. 還好有善心人士照了一個很大的圖.

接著想要透過 debug console 來 reflash 時, 卻發現就算把 DBG/GND 短路後, 再開機, debug console 也沒有任何輸出. 所幸同事觀察到 Zipit 會有一個綠燈一閃一閃的, 想說會不會是debug console 本來就不會有輸出. 於是就根據說明 利用upl盲目上載相關檔案(zpm.bin, loader.bin, ramdisk.gz, zimage.dat)

將 DBG/GND 開路, 拔掉 AC 電源再插入, 果然就看到企鵝了.
接下來, 就是 試試看囉. 我用 root 登錄(不用密碼), 看了一 /proc/meminfo (約 14 MB), 執行 df (ramdisk 約 5 MB). 挫折比想像中的少, 蠻高興的.

註 1: zpm.bin (Zipit-PreBoot-Monitor)/loader.bin 的 source. 由下面的 rom mapping 可以知道為什麼最大只能有 2KB.
註 2: zipit 的 rom mapping

00000000	boot loader (no GPL source)
00002000	start of kernel zImage compressed bootloader
000045B0+-	start of gzipped Linux data (inside zImage)
00090000	start of gzipped Linux ramdisk image (over 4MB expanded)
001F0000	Flash stored properties -- "AerMedia Properties"
001FFFFF	end of FlashROM (2MB)

註 3: OpenZipIt 是個不錯的進階.
註 4: ZipIt Peek & Poke 有列出一些 Port/GPIO 的用途.
註 5: ZipIt 應用程式開發說明有一些不錯的 Link.
註 6: flash_notes.txt 對使用 debug console 來 reflash有更詳細的說明. 這個 網站 的說明還不錯.

checksum for selected files on flash disk is verified

今天 chris 有測到 發生 flash file corruption 的情況, 而且 gps.exe 可以正確認出, 並且避開問題.
再跟 Jason 通e-mail/電話. 確認狀態後, 又和 Jason 討論了一些關 over the air download 會遇到的問題. 要我想一想是否有解決方法 (我沒有~, 寫封 e-mail 告訴他)

checksum for selected files on flash disk

今天將 checksum feature 加入 terminal 以下功能中
usrvar.dat(usrvar.mir), msg-*.dat (msg-*.mir), pws.cfg(pws.mir), trip.dat(trip.mir)

比較特別的是 msg-*.dat(msg-*.mir) 似乎有點奇怪. 從 disk image 讀出來的一致的, 但透過 xdos 讀到的內容卻是不一致. 透過 debug 模式, 觀察到確實有將相同的資料寫入, 就先不找了.

接下來就是交給工程人員測試.

本週待辦事項 (2007/03/05-2007/03/09)

星期二早上 要去 Siemens 討論關於 RTB 方面的事情
星期四下午, 會有關於 SIP 密錄方面的公司來 Demo.


另外. 應該要開始閱讀 Zipit 相關的資料了.

finally, the terminal ap with direct FAT access is done

星期五下午, 終於攪定這一部份, 接下來就是要上線測試了.

很期待下一個關於 embedded linux 的 project. 希望會有好的結果.