星期五, 4月 24, 2009

SecuTech Expo 2009 台北國際安全博覽會 觀後感

在SecuTech Expo 2009 台北國際安全博覽會，參觀了不少Surveillance 廠商，其中當然免不了有一些賣奇怪東西的廠商，例如：消防器材、防身電擊槍…etc，還有極少數的廠商如學校單位提供技術轉移，PTZ機構馬達等週邊廠。

在場的DVR的廠商，大多所展出的商品都還停留在 Resolution D1/CIF的規格，由於近年來LCD電視規格提升至1920x1080，畫面輸出部份已有頃向將數個D1 or CIF 的小畫面組合成 1080p/I 再輸出至Full HD 的電視畫面。就Video Server的功能性，其實跟DVR相去不遠，除了少了顆硬碟與儲存功能，幾乎跟DVR沒甚麼兩樣，也造就了如：NVR( Network Video Recorder)等許多的怪名詞。

IPCam 的部份，今年所主打的Mega 級H.264 的廠商也不算少，但看的人都集中在某些攤位，然而公司的產品也還是有不少人去看，當場看到了幾個現像是值得注意的。

Surveillance:

l 某些小公司一樣有Demo H.264的IPCAM 卻沒人駐足，攤位小連看的人都沒有，不過我在那看，其實畫質及操控並不輸我們的產品，雖然產品好很重要，但畢竟我們還不是世界大廠，攤位大小、門面也非常重要。

l UI 的簡化是一個驅勢，旁邊偷聽了一些在詢問廠商設計問題的客戶，很多都是畫面操作的問題，而會場上所展示的畫面，大多也幾近無設定的畫面，畢竟大多數的使用者設定完後就不太會去動了，實在是很少使用設定。

l Object Tracking、Video contain analysis 不少，但大多是Windows plateform下以Software Application 模式下運算，極少數以Hardware 方式實現。

l 3G mobile、Two-way Audio via SIP protocol、PoE(802.3af) 等幾樣規格也漸漸上了IPCam，似乎是要把所有的規格弄進小小台的IPCam 才爽、才叫高級，不過真的有多少User在問在看是個問號？大家走來走去可以聽見的是都在看畫質、即時性、FrameRate、CPU損耗等議題。

Digital Home:

l Home care :
不少整合商將數種異質性產品整合，朝居家安控發展，雖然這已推廣多年，但都是換湯不換藥，一樣的東西，沒有一點創新，跟中X保全、新X保全所能提供的沒啥兩樣。

l New Item：
其中在會場中遇到一間叫Netvox，雖然那個看起來像經理的愛理不理，態度極差，不過我還是追著他猛問，這家在做ZigBee( IEEE 802.15.4) RF Module，其中有另一間KOBI IZEX-KOBI Technology Co., Ltd.也引入ZigBee的概念，目前項應用在監控甚少看到人整合。ZigBee，可將週遭的Sensor 狀態，透過低功率無線傳輸至ZigBee AP，再由AP 上Internet，然而只需要用電池就可以維持 1~ 2年的使用時間，目前要使用無線I/O 這個低價又可以無線傳輸，更有綁規格的機會，成本又低，不知道為何沒有幾家在整。

l Door phone：
有幾間在做Door phone，其中有簡易型，有搭配MID(Mobile Internet Device)，利用MID可隨處上網的特性，直接將Stream/家電/Sensor 等納入，達到Digital Home Controller Center 的概念，但不論是簡易型還是高級型，由於MID or mini LCD都約為5 ~ 9吋畫面且不易關看，畫面UI 看起來都是需要美工處理，而非文字型態，在Embedded Linux下侼為棘手，有時甚至會受限平台，故平台需慎選。

Plateform Design:

l H.264 SOC chip:
這次有看到TI TMS320DM3xx 系列，由歐普羅代理，該RD指出 IP Camera Reference Design要到六月份才有，現在買Board沒甚麼用。不過要是跟他們買，Windows 端AP 沒有Source Code，我看一點也沒用 @@，有問題又不能改，看來要用源頭還是在TI。

l 據DM指出 Vivotek 其中有一款型號如下，不過沒看到機器：
型號: IP8161: 2Megapixel x H.264
CPU: TI DM365 Soc
Flash:128MB
Ram:256MB
OS:Linux 2.6
Format: H.264/MPEG4/MJPEG
MAX Resolution: 1600x1200x10fps

Conclusion:

1. 會場中不乏MPEG4產品，也有人在比較Performance議題，然而在 CMS整合廠商中，多組IPCam/DVR影像的輸入所耗費的CPU資源直接影響到CMS所呈現的效果，雖然H.264在儲存空間、使用頻寬等皆佔有許多優勢，然而在 Windows plateform 下Software Decode效能、價格與MPEG4相較卻略遜一截。

2. 同第1點所述，PM及業務方面是否有釐清目前公司方向，H.264平台客戶的需求，亦或客戶群皆為價格導向，對於壓縮平台是否著重於H.264/MPEG4 的差異，IPCam本身的特性並不提供錄影儲存媒體，然而在Windows Client端，目前Storage Size 也日趨龐大，價格也幾近論斤賣，若能以低價取得相同的畫質，MPEG4也不失為一個選擇。但H.264也代表著公司開發技術能力，如何在有限資源下達到相同的效果，也是屬於一種不可缺少的指標性產品。

3. 將IPCAM 作到幾近DVR的強大功能，使得Spec能條列出多功能亦是不錯，但倘若將火力集中於開發大多數客戶想要的功能，是否能發揮更大效益，是否遠比開發出數十個沒用的小功能更具有賣像？

4. 爾後的展覽應派遣RD駐場，雖然大多的問題公司內FAE/PM等都能回答，但在會場觀察了幾個小時，不論是公司大小，大多的公司在被詢問到較專業性問題時，該公司即派當場RD回覆，除了能提升公司專業領導的品牌形像，對於客戶再次詢問詳細問題的意願也較高。

5. 人臉及行為模式的辨認似乎有不少買家(掛菊色的牌子)在看，這個功能在Windows端也能做到，是不是要在Server端處理就只能看Plateform provider了，雖然目前公司沒有人力做這塊，然而這很像是趨勢，需要高度觀察。

張貼者： Jack 於 3:17 下午 2 意見
標籤：

星期一, 4月 20, 2009

NoneBlock sendfile


一般copy 的狀況下
  1. 從HW 的資料透過DMA 搬移至Kernel
  2. 再從 Kernel 搬至User space，送到Socket 時再搬依次。
  3. CPU Copy x 2 + DMA x 2
使用mmap + write 的狀況：
  • 從HW 的資料透過DMA 搬移至Kernel
  • 直接從 Kernel space 將Buffer搬至Socket buffer。
  • 缺點：當User/Kernel space 兩塊同時操作時須有解決方案，多了sendfile 一次的context switch。
  • 優點：當要送至socket時有sendfile的效能，user space也能存取資料。
  • 花費：CPU Copy x 1 + DMA x 2

使用Sendfile 的狀況：
  • 從HW 的資料透過DMA 搬移至Kernel
  • 直接從 Kernel space 將Buffer搬至Socket buffer。
  • 缺點: User space 無法取得資料。
  • 花費：CPU Copy x 1 + DMA x 2
較佳的方式：
  • 從HW 的資料透過DMA 搬移至Kernel
  • 利用HW support gather 的方式，直接從 socket/kernel dscr pointer 利用DMA gather的方式將資料直送底層。
  • 這個步驟目前還不確定方式，目前看來從AP層好像沒有現成的，要從Driver request DMA channel，setup, start 等動作，要找一下。
    asfd
  • 缺點: 需要HW support。
  • 花費：DMA x 2

DMA的操作，基本上DMA的動作，需要follow HW Handshaking，基本上會跑類似下列流程：

  • request_dma()
  • dma_setup_handlers()
  • dma_config_src()
  • dma_config_dst()
  • dma_setup_single
  • dma_enable
  • ==> wait for transfer complete event
  • dma_disable
  • dma_free
  • MultiBlock 的話還需要設定 setup_sg or setup_mlist








下面例子用以前寫的socket function測試，listen/connect 不列出來了，主要是測試 NoneBlock sendfile 的狀況，以及 EAGAIN 旗標產生的主因。( client/server在同一台機器)

以下四種狀況都會影響到Client side 每次下send 的大小。
  • Client 端 connect target ip = 192.168.1.85 or 127.0.0.1
  • Server端收到就丟棄。
  • Server端收到後存檔。
  • Server端收到後印出收到Size。

Server Side Code:

#include <stdio.h>
#include <stdlib.h>
#include <socketServer.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>


int     fd, times=0;
void callback( int fd, unsigned char *buf, int size ){
//      printf("MyFunction:\n FD[%d] str=%s size=%d\n", fd, buf, size );
//      printf("[%d] MyFunction:\n FD[%d] size=%d\n", times, fd, size );
//      fd = open("server.dat", O_WRONLY | O_APPEND );
//      write( fd, buf, size );
//      close( fd );
times++;
}

int main( int argc, char ** arg  ) {
SOCKET_SERVER server;
int     ret;
system("rm server.dat;touch server.dat");
// use User Define Callback
#if 1
ret = server.initServer( 9600, callback );
#else
ret = server.initServer( 9600);
#endif
printf(" server ret =%d\n", ret );

while ( 1 )  {
server.clientList();
sleep(3);
}
return EXIT_SUCCESS;
}



Client Side Code:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <socketClient.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/sendfile.h>
#include <errno.h>

int main( int argc, char ** arg  ) {

SOCKET_CLIENT client;
int ret;
int fd;
//init sock
//ret = client.initClient( "127.0.0.1", 9600 );
ret = client.initClient( "192.168.1.85", 9600 );
if( ret != EXIT_SUCCESS ){
printf("Client create FAIL ret=%d\n", ret );
}

//send mydata
fd = open( "mydata", O_RDONLY);
int     times=0;
size_t  r;
off_t   offset = 0;

struct timeval          tv;
fd_set                  wfds;

while( 1 ){
FD_ZERO( &wfds );
FD_SET( client.m_iFD, &wfds);
tv.tv_sec = 1; tv.tv_usec       = 0;
ret = select( client.m_iFD+1, NULL, &wfds, NULL, &tv);
if ( ret <= 0 ) printf("timeout or ret=%d\n", ret );

r = sendfile( client.m_iFD, fd, &offset, 1024*1024);
if( r == 0 )    break;
if( r == -1 ){//&& errno == EAGAIN ){
  printf("EAGAIN\n");
  continue;
}
printf("[%d]sendfile offset=%d r=%d \n", times,(int)offset, r);
times++;
}
return EXIT_SUCCESS;
}



Run: 可以看到連下兩道後的結果並不相同，但Server端是相同的，且不會出EAGAIN，EAGAIN發生的時機點為連下兩道sendfile才會發生，select 當次即使是送不完也不會發生。也就是說EAGAIN這個flag 是在ret = -1 時產生，buf 裡的位置為0 才會發生。
[root@192 ipSock_noneblock_sendfile]# ./client
[0]sendfile offset=1048576 r=1048576
[1]sendfile offset=2097152 r=1048576
[2]sendfile offset=2179072 r=81920
[3]sendfile offset=2785280 r=606208
[4]sendfile offset=2949120 r=163840
[5]sendfile offset=3112960 r=163840
[6]sendfile offset=3276800 r=163840
[7]sendfile offset=3440640 r=163840
[8]sendfile offset=3604480 r=163840
[9]sendfile offset=3768320 r=163840
[10]sendfile offset=3932160 r=163840
[11]sendfile offset=4096000 r=163840
[12]sendfile offset=4259840 r=163840
[13]sendfile offset=4423680 r=163840
[14]sendfile offset=4538368 r=114688
[15]sendfile offset=4685824 r=147456
[16]sendfile offset=4833280 r=147456
[17]sendfile offset=4964352 r=131072
[18]sendfile offset=5095424 r=131072
[19]sendfile offset=5226496 r=131072
[20]sendfile offset=5554176 r=327680
[21]sendfile offset=5898240 r=344064
[22]sendfile offset=6045696 r=147456
[23]sendfile offset=6193152 r=147456
[24]sendfile offset=6324224 r=131072
[25]sendfile offset=6455296 r=131072
[26]sendfile offset=6586368 r=131072
[27]sendfile offset=6717440 r=131072
[28]sendfile offset=6848512 r=131072
[29]sendfile offset=6979584 r=131072
[30]sendfile offset=7110656 r=131072
[31]sendfile offset=7241728 r=131072
[32]sendfile offset=7372800 r=131072
[33]sendfile offset=7503872 r=131072
[34]sendfile offset=7634944 r=131072
[35]sendfile offset=7766016 r=131072
[36]sendfile offset=7897088 r=131072
[37]sendfile offset=8028160 r=131072
[38]sendfile offset=8159232 r=131072
[39]sendfile offset=8191034 r=31802
[root@192 ipSock_noneblock_sendfile]# ./client
[0]sendfile offset=1048576 r=1048576
[1]sendfile offset=2097152 r=1048576
[2]sendfile offset=3145728 r=1048576
[3]sendfile offset=4194304 r=1048576
[4]sendfile offset=4538368 r=344064
[5]sendfile offset=5586944 r=1048576
[6]sendfile offset=6635520 r=1048576
[7]sendfile offset=7684096 r=1048576
[8]sendfile offset=8191034 r=506938


Conclusion:
  • 查了一下原因，也許跟下面有關，不確定，把wmem_max值加大，當busy時send出去的值就會接近設定的值。
    cat /proc/sys/net/core/wmem_max
    131071
  • 為何要用sendfile
    1.減少TLB cache flush，使用read/write function會導致 cashe 異動。
    2.減少kernel/user space context switch 次數。
    3.Copy 次數減少。
  • 長遠來看 IPCam/ DVR 長時間處理影像傳輸，應該使用第四種方式，減少CPU Loading，除了增加Performance，還可以增加 Client 的 Throughput。
張貼者： Jack 於 4:52 下午 0 意見
標籤：
訂閱： 文章 (Atom)