星期五, 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.264IPCAM 卻沒人駐足,攤位小連看的人都沒有,不過我在那看,其實畫質及操控並不輸我們的產品,雖然產品好很重要,但畢竟我們還不是世界大廠,攤位大小、門面也非常重要。

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

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

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

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了,雖然目前公司沒有人力做這塊,然而這很像是趨勢,需要高度觀察。

星期一, 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。