“流量控制，P2P应用的识别与控制系统–Panabit”有114个回复

1. Panabit 于 2009-04-28 7:32 下午

   能够入陈怀临先生”法眼”，我们感到非常荣幸，这也将成为我们不断努力的动力！对于4Gbps，我们的硬件配置必须是双核（当然，一般的双核就够了）。从技术角度看，我们还有很多路要走，因为应用识别和控制这个领域是一个需要不断更新和优化的领域，比如，我们还需要不断优化PSDL语法和编译器，今年我们也将增强PANAOS,比便可以支持更多的核。
   您所提的问题我们一定谨记！

2. 图书管理员 于 2009-04-28 9:23 下午

   策略控制，包括NBAR, DPI/DPC 类产品，很多公司都有。有做独立平台的，也有集成在路由器中做成service card的。Heavyreading去年年底有一个分析报告是关于这方面的。
   这里面的难点是支持的速率和软件更新。
   我个人更感兴趣离线的分布式策略管理架构，如果能和edge router的classification/policing结合将更具使用性

3. LostGhost 于 2009-04-28 11:52 下午

   Panabit Mao?

4. 某某 于 2009-04-29 1:28 上午

   他们不一定需要和大公司竞争，千金马骨也行啊

5. 陈怀临 于 2009-05-01 8:45 上午

   另外，对流控感兴趣的读者也可以了解一家公司：网康科技。

   http://www.netentsec.com/product/product.htm

   他们是做系统的。直接卖box。

6. 老韩 于 2009-05-03 9:22 上午

   支持Panabit，我们一直都在用。

7. ABC 于 2009-05-04 2:18 上午

   其实国内做流控的不下十几甚至几十家。网康算是做的不错的，不过还有几家也做得可以。百卓的东西从ARM，NP到多核都包括了。城市热点则是在自有系统上进行了优化。
   包括国内做系统做的比较好的立华，对多核做了很多开发。还有一个老朋友也在做系统，海拓天成，也是基于cavium做的。

8. 陈怀临 于 2009-05-04 6:21 上午

   谢谢ABC。很好的信息。是的，Panbit能否持续发展，做出高端解决方案很重要。否则，其优势会在1，2年之内被人赶上来。居安思危呀。。。

9. 老韩 于 2009-05-04 8:00 上午

   我觉得，国内还没有一款非常好的流控产品，大家各有各的问题。

10. 陈怀临 于 2009-05-04 9:12 上午

    小韩，愿闻其详。

11. 老韩 于 2009-05-04 9:36 上午

    主要是市场和需求还不成熟，缺乏重量级厂商和革命性产品。市场上可见产品要不可用性（功能、性能、稳定性、对新应用的响应速度）不过关，要不营销还有待加强。陈老师介绍的Panabit不错，我们一直在用，稍后我也会写一篇文章说说。

12. 老周 于 2009-05-06 10:46 下午

    目前正在测试一款天网的流量整形系统，感觉x86+linux的架构，吞吐量等方面还是有缺陷的。

13. 陈怀临 于 2009-05-20 9:34 上午

    是的。对于Panabit而言，我个人感觉也是其能否在高端市场展开。当然，这涉及的问题相当多，不仅仅是技术。能进入电信级别的客户，需要强大的公司背景，客户支持，与现有设备的互联，互通，是一个完整的deployment。

    在技术上，确实是存在Panabit能否scale的问题。

14. 网路游侠 于 2009-10-03 3:39 上午

    最近做流控的很多的，像博主写的网康，另外有深信服、QQSG等，国外的有WebSense、AceNet、L7等，做的都不错。Panabit做的比较不错，关键的是256人的网络免费了……呵呵

15. 过客 于 2010-01-13 12:06 上午

    不知道panabit关注企业内网流控这块市场不？
    对企业内部众多应用的识别是如何支持的？

16. Panabit 于 2010-01-13 3:16 上午

    回楼上：我们一直在关注，目前主要是开放完全免费的标准版让企业客户免费使用。对于应用识别，很多标准版用户都在给我们反馈和抓包。我们的协议更新基本上都是用户需求驱动的。

17. 陈怀临 于 2010-04-21 8:56 下午

    这几天一个小弟通过我（弯曲评论）与Panabit 套瓷。。。

    YY一下：

    1. Panabit现在的名声可是真大了。
    2. 弯曲和首席的名声可是真大了。

18. alrn 于 2010-09-15 2:25 上午

    支持的协议:
    1) HTTP协议：web视频(优酷，酷六，六间房，YouTube，土豆网，Hulu，Sohu视频，Sina视频，我乐网，腾讯宽频，i酷，凤凰网，CCTV点播，Viewgood，PPLive视频，芒果TV，激动网，奇异视频，其他Web视频)，HTTP下载(伪IE下载，HTTP分块传输，其他下载)，HTTP上传(QQ硬盘上传，其他HTTP上传)，Flash，Web音乐，HTTP代理，WWW。
    2 ) 常用协议：电子邮件(SMTP，POP3，IMAP)，Telnet，FTP，DNS，DHCP，TFTP，SNMP，NFS，NTP，CVS，NETBIOS，Microsoft-DS，Remote-Sync，远程桌面，Socks4/5，UPNP，SYSLOG，DAYTIME，DECRPC，LDAP，360更新，Nod32更新，卡巴斯基更新，Windows更新，NAT端口映射，ISA，游戏维护(易游，左轮，强者，i8，MZD，起凡补丁下载)，迅闪，网维大师，STUN，GIOP，WinBox，Radmin。
    3) P2P下载：BT系列协议(BitTorrent，BT扩展协议，BT加密协议)，eDonkey，Poco，迅雷，Gnutella，Fasttrack，DirectConnect，AppleJuice，百度下吧，百宝，酷狗，Vagaa，Ares，Napster，Mute，iMesh，SoulSeek，WinMX，脱兔，PPGou，天网Maze，搜娱，PP点点通，酷我音乐盒，RaySource，超级旋风，Flashget，汉魅，P8，Foxy，aMule，顶悦视听盒。
    4) 网络电视：PPStream，PPLive，沸点，乐酷，QQ影音(QQ直播，QQ音乐)，CCIPTV，TVAnts，TVKoo，PPMate，MySee，悠视TV，极速酷6，QVod，PPFilm，迅雷看看，SopCast，VJBase，JeBoo，风行，青娱乐，飞速土豆，BOBO，Netitv，新浪电视直播，搜狐电视直播，iV影音加速器，乐鱼，暴风影音，央视电影频道，葫芦网，久久影音。
    5 ) 即时通信：腾讯QQ(QQ聊天，QQ文件传输，QQ视频聊天，TecentMessager，QQ音乐)，MSN(MSN聊天，MSN视频)，雅虎通，GoogleTalk，新浪UC，新浪UT，AIM，IRC，UC视频聊天，网易泡泡，阿里旺旺，淘宝旺旺，Lava-Lava，飞信，百度hi，Teamspeak，腾讯RTX。
    6) 股票交易：钱龙系，大智慧，同花顺，大福星，富远行情，大有期货，宏汇软件。
    7) 流媒体：RTSP，RTMP，MMS，QuickTime，BBSee，WMPlayer，RealPlayer，磊客，新浪奥运视频，网易奥运视频，QQ奥运视频，央视高清，千千静听。
    8 ) 网络电话：Skype，H.323，SIP，UUCall，ET263，MGCP，铁通飞线，Net2Phone，铁通RedVip，Vtalk，SIPhone，KC网络电话。
    9 ) 网络游戏：第九城市(魔兽，奇迹世界，卓越之剑)，巨人网络(巨人，征途)，蓝港在线(倚天剑和屠龙刀)，盛大网络(新英雄年代，传奇系列，盛大富翁，彩虹岛，龙骑士，风云，冒险岛，热血传奇，超级舞者，英雄连，诸侯，生死格斗)，世纪天成(跑跑卡丁车)，天游集团(蒸汽幻想)，完美时空(完美世界，武林外传2，神鬼传奇，梦幻诛仙)，卓智时代(纵横时空)，天晴数码(机战/魔域，投名状，征服，91开心游戏)，17game(热血江湖)，光宇在线(问道，希望，西游Q记，神界，炫舞吧)，光通网络(神泣，数码宝贝)，腾讯游戏(QQ幻想，QQ三国，QQ音速，地下城与勇士，QQ游戏)，中广网(武林群侠传)，网易游戏(泡泡游戏，大话西游3，梦幻西游，大话西游2，大话西游外传)，金山游戏(水浒Q传，反恐行动OL，春秋Q传，仙侣奇缘2)，新浪网游(新浪游戏，天龙八部)，中国游戏中心，劲舞团，面对面，街舞，突袭，战火红警，联众世界，凤舞天骄，功夫世界，海之乐章，新魔界，QQ飞车，QQ华夏，QQ炫舞，QQ自由幻想，QQ寻仙，新飞飞，星际家园，生肖传说，霸王系列，勇气OL，超级跑跑 ，冒险宝贝，X-乒乓， 乱武天下， 秦始皇， 穿越火线， 武易， 伊苏战记， 众神之战，三国鼎立， 乱世枭雄，贸易街机，风雷游戏， 魔力宝贝， 浪漫传说， 浪漫庄园， 永恒之塔， 蜀山系列， 浩方对战平台， FIFA On Line， 梦想世界， 弹头骑兵， 星尘传说， 同城游 ， 梦幻古龙 ，梦幻龙族，千年，热血英豪，热舞派对，反恐精英OL，露娜，街头篮球，名将，游戏人生，妖怪A梦，宠物森林，风火之旅，刀剑，对战平台(掌门人，JJ比赛，GCC对战平台，VS对战平台，宽带中国，远航游戏中心，豆客，多多视频(对战平台)，边锋，175平台)，惊天动地，三国群英，倚天2外传，成吉思汗，战地之王，飙车世界，新破天一剑，联众R2，三国策，盛世OnLine，巨星，51炫舞，131玩玩，西游天下，大唐豪侠，大明龙权，秦伤，纳亚外传，梦三国，泡泡堂，龙OL。
    10 ) 网络安全：SSH，HTTPS，L2TP，PPTP，IPSec，GRE，OpenVPN。
    11) 数据库：MSSQL。
    12) 其它：SYN_ACK，ICMP，IGMP，非IP3层协议，其他4层协议，文件下载及视频，在线交互式应用，IP分片，OSPF，BGP，ARP，看天下，PPPOE，内网IP伪装，自定义协议。
    软件性能
    配置适当的硬件，Panabit标准版保证100Mbps线速，专业版完全满足处理双向4Gbps吞吐量。
    软件安装环境
    硬件：Intel x86平台，配置P3 800Mhz以上、256M内存以上、3块网卡，128M以上电子盘或硬盘均可。
    操作系统：FreeBSD 6.2或以上(Panabit 2007仅支持FreeBSD 4.11)。

    ______________________________________

    TNND,太狠了…..人都绿了……

    我们打算采用ATCA平台,RMI XLR732处理器做这样一个模块…..

19. alrn 于 2010-09-15 2:34 上午

    1)是修改驱动实现吗?收到以太网后,在驱动中完成应用开发,不交给OS处理?
    2)数据包流向如何处理走,在网卡中没有搬包吧,收到包,监测完毕,马上把该包扔出去?否则实现4G难呀,关键是PC呀,我的神呢…….

20. Panabit 于 2010-09-16 9:05 上午

    4G是历史了，现在都8G了，20G的也在设计中。

21. GOOGLE 于 2010-09-16 6:15 下午

    遥想3年以前，我正在卖ACENET的BOX卖的不亦乐乎。现在这个市场也红海了，大家东西大都同出一辙，没有什么新意。

22. alrn 于 2010-09-17 12:46 上午

    to Panabit :
    能够透露一点开发信息?采用PC如何实现这么超NB的功能?!

23. 辉 于 2010-09-17 12:48 上午

    加快10G的FPGA卡就行了呗

24. xian_wang 于 2010-09-17 2:37 上午

    Panabit 于 2010-09-16 9:05 上午 4G是历史了，现在都8G了，20G的也在设计中。

    8G和20G是基于什么硬件？还是X86吗？

25. Panabit 于 2010-09-17 3:37 上午

    会楼上的，是基于X86的。

26. shuttle 于 2010-09-17 5:04 上午

    不知道4G和8G都是对于平均包长么，若是短包的话还能达到如此高的速度么，朝着20G去的话觉得很夸张，几乎要到单向metro switch的速度了，那改造一下岂不是可以当高端路由器来卖了

27. Panabit 于 2010-09-17 5:23 上午

    8G目前还不是小包，不过小包可以到3G+.所以平均包长应该可以到8G。

28. droplet 于 2010-09-17 7:22 上午

    设计是指软件设计，还是硬件设计？如果单指软件设计，那么就是说现在基于x86平台的工控机性能已经可以和专用平台媲美了？

29. Panabit 于 2010-09-17 7:47 上午

    回楼上，就是用一般的X86工控机，不需要特殊的硬件设计。X86的性能其实已经很强了，早就不是当初PCI时代的X86了。

30. alrn 于 2010-09-18 6:41 下午

    to Panabit:
    能够透露一点设计的细节吗?大家太想知道是如何实现的,谢谢!

31. Eric 于 2010-09-18 8:15 下午

    是不是传说中的DPI，国内国外已炒作好几轮了
    国内厂商:南京信风/宽广电信/QQSG/金御/绿网/兆维晓通/阳光金网，国外：Cisco/sanvine/allot/arbor/procera/anagran/………

32. Panabit 于 2010-09-18 9:21 下午

    协议识别只能说是DPI的一个分支，DPI包含的范围比较大。这个领域厂家很多，你上面说的有不少也已经快消失了，但是又有后来的不断补上。我们在这个领域还只是小蚂蚁一只，所以要想立足，必须专注。X86上实现20G的协议识别和流控，碰到的细节问题和在其它的多核上是一样的，主要的还是特征库和引擎的效率，以及在并发方面的处理上。这几年X86发展很快，是完全有能力做到这一点的。如果换着Cavium或RMI等多核，大家可能觉得很正常，而X86就觉得不正常，我觉得主要还是因为在X86下，大家普遍采取拿来主义，没有好好的沉淀一下。

33. Panabit 于 2010-09-18 9:24 下午

    回30楼：我会在后面和老韩一起，通过文章来一步一步说明我们在性能方面的改进过程，当然这个文章肯定是在弯曲上发布的。

34. 老韩 于 2010-09-18 11:12 下午

    1.顶楼上 2.我对不起你

35. Panabit 于 2010-09-18 11:59 下午

    你有啥对不起的:)，做这个本来就是我们俩的兴趣，和商业无关，呵呵。

36. 辉 于 2010-09-19 5:33 上午

    搬个板凳听讲，听听非FPGA方案和非Cavium方案怎么上8G

37. 老韩 于 2010-09-19 6:15 上午

    楼上可以找intel的文档看看，在Xeon5500平台下小包裸奔也可以到10Mpps+

38. Panabit 于 2010-09-19 6:33 上午

    根据我们上次测试的结果，裸奔的话，2个核就可以超过10Mpps了。

39. droplet 于 2010-09-19 10:08 下午

    通用操作系统需要定制，最好是一个小的核，然后上面开发自己的应用。通用操作系统太重量级了，裸奔都不好跑。

40. 嘻嘻哈哈 于 2010-09-19 10:24 下午

    同感，现在的FreeBSD 8就是mess

41. Panabit 于 2010-09-19 11:28 下午

    我们就是在FreeBSD 8上跑的，当然，数据处理是在Panaos里的。内核大没有关系，只要你的应用所经过的路径不多就OK了，路径没经过，代码就没有执行，多了怕什么？

42. 理客 于 2010-09-20 1:57 上午

    转发性能的关键是一个报文处理流程占用多少实际的CPU cycle,优化都是基于此为目标

43. hritian 于 2010-09-20 2:52 上午

    差不多，我们在网卡驱动上做小包转发，linux系统，单核500Mb。CPU是5504。
    据人转述章文嵩的话说，在freebsd上用多队列网卡跑LVS，小包能到10G

44. 嘻嘻哈哈 于 2010-09-20 3:03 上午

    To 41楼：

    不清楚你是怎么做的，可能你把应用放在User space 而不是 kernel land.
    1.在数据报文Receive/send路径上的瓶颈：
    - 从网卡的input queue接收和处理报文，除了多队列网卡，其他网卡都只是支持一个input queue，对应一个中断，也就是说只能用一个Core。
    - 在网卡驱动和其他network stacks的Cache line contention，这是stats data structure决定的
    - 保护connection list的Global locks，对于UDP已经可以做到避免write locks,对于TCP，必须对于每个packet生成一个global lock
    - 如果user application是多线程，会导致file descriptor table lock contention

    2.在transmit路径上，类似的瓶颈

    这些都是内核基本的问题，如果这些问题都没解决，Core越多，性能越低

45. Panabit 于 2010-09-20 3:58 上午

    心中无刀，才能杀人于无形！

46. 老韩 于 2010-09-20 4:37 上午

    越来越有意思了

47. julang3 于 2010-09-21 5:50 上午

    之前在x86 上做过包转发的性能优化；x86上linux内核包处理的主要有2个地方：
    1. 驱动层的buffer管理，收到1个包，进行1次buffer重分配，填充到dma ring desc,每发一个包，释放buffer内存到内核；
    2. linux内核协议栈对包的解析，会严重影响cache命中率；
    如果要实现自己的高性能包处理，建议直接hook驱动的收包，发包函数；完成自己实现；这样内核协议栈的问题，驱动实现的问题都可以避免掉

48. Panabit 于 2010-10-13 3:53 上午

    号外一下，今天在性能方面又有一些进展。裸奔的话，单核的pps从以前的600Wpps提到到目前的900Wpps，下一步看能否到1000Wpps，之后看SMP方式下的扩展性如何。

49. 老韩 于 2010-10-14 8:47 上午

    这么高调干啥，x86的潜力还很大，先做到2000万PPS再说吧……

50. multithreaded 于 2010-10-15 3:39 下午

    用多少个核才能做到20Million PPS？

    用libpcap把包发到用户层， 才更有意义。 不过多复制一次，会有损失的。

51. Panabit 于 2010-10-15 7:50 下午

    回楼上：根据目前的结果，4个核足够了。

52. Panabit 于 2010-10-15 7:58 下午

    BTW，我测试的这个数据包是到用户态的。

53. 老韩 于 2010-10-18 4:13 上午

    力顶Panabit，来自计算机世界的犀利观点:D

    btw，前一阵华赛办大型产品发布，貌似很多新产品都是可以插x86业务槽的……x86做L5-L7，multicoreMIPS做L2-L4，开始进入主流。

54. stormplayer 于 2010-10-18 4:49 上午

    请panabit兄，不要生气。
    个人感觉panabit的目标也不是跟一些大公司去比的，毕竟人力、资源等都跟不上，要不就拔苗助长了，只要自己能有个目标小市场，赚的锅满盆满就可以了。

    据说山石的Qos做的也很不错，刚出的百G firewall的一块QSM卡的64byte小包也能到3G，能支持的ip queue 个数达到 2000K ，而且据说用的还是一块比较low level的cpu，哈哈！

55. Panabit 于 2010-10-18 6:49 上午

    Stormplayer兄弟：我就没有看到有啥要生气的，呵呵。其实我们做Panabit，最主要的还是个人的兴趣，比如调X86的性能，这都是主要从兴趣出发。你说得很对，就我们的规模，和那些大的比，就是一只小蚂蚁，没法比的。所以我们能做的，就是尽量做专，将核心的那一点东西做到极致，这就够了，呵呵。山石的技术是不错，里面也有不少熟人，相互比较知根知底。

56. l7sec 于 2010-10-31 12:53 上午

    呵呵，在X86上做到8G有点搞笑了。。。自娱自乐可以，出来唬人就不太好玩了。毕竟这里还是有很明白的人，能做好自己中小企业的东西市场就足够大了。

57. sec 于 2010-10-31 12:53 上午

    呵呵，在X86上做到8G有点搞笑了。。。自娱自乐可以，出来唬人就不太好玩了。毕竟这里还是有很明白的人，能做好自己中小企业的东西市场就足够大了。

58. Panabit 于 2010-10-31 1:18 上午

    唬人？我QQ是896416263，你有种来找我，我给你一个实际的例子看看。

59. Panabit 于 2010-10-31 1:28 上午

    你如果不用QQ的话，我还有MSN: softmic_msn@hotmail.com，看看是我搞笑，还是你无知。NN个屁，我在这里混了这么久，还从来没有听到哪个老大说我搞笑，唬人。

60. 陈怀临 于 2010-10-31 1:30 上午

    kakaaka,我大弟子生气了。后果很严重。。。

61. Panabit 于 2010-10-31 1:59 上午

    唉，首席，一个醉心于技术的人，最忌讳别人说你唬人、搞笑了。而且他同样的话，用不同的ID再重复一遍，你说是不是气人？！

62. 陈怀临 于 2010-10-31 2:14 上午

    是，严重苟同。同学们，要对Application Aware Operating System敏感些。

    这也是我在3天之后的一个鸟高峰会论坛上的主要演讲精神。。。

    先透露一哈。。。

63. 老韩 于 2010-10-31 8:14 上午

    在安全产品领域，一切看不起x86的观点都是纸老虎。

64. multithreaded 于 2010-10-31 8:51 上午

    讨论Gbps没有太大的意思， 如果是大包， 8G-10G是能做到的。 难点是小包的速度上不来。所以我说山石做的不好，小包的速度达不到线速的20%。

    我比较开好Panabit，因为他说能做到9MPPS ：-）

65. multithreaded 于 2010-10-31 8:52 上午

    #62， 是不是跑题了！ 我记得主题应该是 Challenging of 。。。。Programming

66. 理客 于 2010-10-31 11:49 上午

    做过系统处理性能优化的都清楚，任何一个可编程系统，包括FPGA，都是可以性能优化的，但同时在达到一定高度后是非常难的，前一个版本限速，下一个版本就可能大幅下降，这种案例数不胜数，这也是大型软件在增加功能时如何保持性能优化结果的一个大难题之一

67. sec 于 2010-10-31 4:44 下午

    hehe, 止怒。。。如果64-512 的包都能做到的话，真的NB。还能挑战一下PCI总线的宽度。
    无非就是把网卡数据送到用户空间来进行处理，理论上能达到。实际做起来就是另一码事情了。我也做到过限速传输，但上了几百个应用之后，呵呵

68. sec 于 2010-10-31 4:47 下午

    做技术的人，最忌讳的就是绕在自己的思维圈子了，而听不到外面的声音。夸奖太多了真的是好事吗？

    就此闭嘴，不再参与讨论！

69. Panabit 于 2010-10-31 5:13 下午

    呵呵，谢谢楼上的，昨天我的言语有些过激了，抱歉！目前来说，64字节是做不到8G线速的，目前能做到200字节左右8G线速，就是说，目前能做到500Wpps左右。但是这个测试数据是2544测试的结果。从实际应用看，由于会话数众多，会导致CACHE结果表现和测试仪测试时的表现不一样，所以一般只能打对折，也就是实际中可以维持在250Wpps左右的性能。从我们目前掌握的实际数据看，250Wpps在实际中是超过8G的，这和以前预估的是一致的。大家千万不要以为X86还是以前的X86，今非昔比了，裸奔的话，单核都能跑到9M+pps。这些数据都是真是的数字，绝不是我信口雌黄。

70. 理客 于 2010-10-31 5:47 下午

    实际应用确实一般不需要64字节线速，但在专业测试，比如电信测试中，一般都要测64字节的数据，一般来说，大体是正比关系，200字节8G线速，64字节大概就是3G左右。对于IP设备或者包处理设备，一般用pps做性能单位是最准确的，也不容易有误解或者水分

71. droplet 于 2010-10-31 8:20 下午

    还有per packet instruction的估算，相同的功能，用的instruction越少，性能越好。不过这些活太细了，要靠积累。

72. Panabit 于 2010-10-31 8:31 下午

    是呀，协议识别就是一个细活，也是一个苦力活。(:

73. Panabit 于 2010-10-31 11:19 下午

    回67楼：现在早就不是PCI或者PCI-X的时代了，目前已经步入PCIE的时代了，PCIE的带宽远非PCI或PCIX能比。

74. 李忠 于 2010-11-01 10:01 下午

    弱弱地问一下，哪里能找到PCI-X的带宽资料。。。现在的PCIE能做到多少？

75. Panabit 于 2010-11-01 10:30 下午

    PCIX最大带宽为133M * 64 = 8G，是共享的。PCIE看版本，目前主要是2.0的（很快就3.0了），2.0的貌似一个LANE是5G，按照8/10编码，有效带宽是4Gbps，PCIE是独占的，就是每个方向都是这么大的带宽。对于一个PCIE * 16的通道而言，相当于每个方向64Gbps了。3.0的貌似是8Gbps（有效带宽）。

76. Lucifer 于 2010-11-02 11:50 下午

    75楼说的都是bps，PCI-X 3.0可以达到1066MHz * 64bit = 8.53Gbps，然而基本上没有实际产品，有的只是PCI-X 2.0，可以达到533MHz * 64bit = 4.26Gbps……133MHz是PCI-X 1.0的规格

77. Panabit 于 2010-11-03 12:58 上午

    嗯，是的，PCIX-3.0的东西，还从来没见过。Lucifer，你的是B，而不是b吧？

78. Panabit 于 2010-11-03 1:06 上午

    感谢Lucifer，我脑子固有的8Gbps原来是1.0版本的，看来思维惯性还是害人非浅，某天突然发现自己认为是这样的东西，原来不是这样的。唉，还是要努力学习呀。

79. Lucifer 于 2010-11-03 1:08 上午

    回Panabit，是bit和bps

80. Panabit 于 2010-11-03 1:14 上午

    那533M * 64bit = 4.26Gbps是怎么计算的？

81. Lucifer 于 2010-11-03 1:24 上午

    啊……这个确实是GBps

82. Panabit 于 2010-11-03 1:48 上午

    呵呵，我就说呢。

83. siumem 于 2010-11-03 2:25 上午

    例如Cisco的重要的ISR1800系列，3000系列和7000系列。 NBAR可以识别许多流行的P2P的应用程序，例如BitTorrent， Gnutella， Kazaa2， eDonkey， Fasttrack， Napster等等。从某种角度而言，这些技术属于QoS（Policing，Shaping，Rate Limiting)，也可以被认为是网络安全(Policy，ACL Control)的范畴。
    ————————
    思简的NBAR简直就是一跎S，想用NBAR拦BT\EMULE，比登天还难。

84. dcoder 于 2010-11-05 3:13 上午

    请问Panabit ，你测试出来的PPS数据是双向的还是单向的？(一收一发还是两收两发？）

85. Panabit 于 2010-11-05 6:12 上午

    整体性能，双向的。要是单向那么大，那美死了，呵呵。

86. silenthunter102 于 2010-11-08 6:09 上午

    其实从商业的角度上来说，性能基本上已经不是制约产品发展的瓶颈了吧。
    我不觉得在运营商的骨干和汇聚层上会使用7层的QOS产品。吞吐量这么大有什么价值？

87. silenthunter102 于 2010-11-08 6:13 上午

    Panabit 的东西确实在民间有一定的影响力。OEM的厂商也很多，个人觉得流控这个市场确实是红海一片，已经没有什么做头了。

88. Panabit 于 2010-11-08 6:27 上午

    性能是没有嫌低的，在汇聚的地方部署QOS已经很长时间了，有很多运营商也这么干了。DPI个人觉得是今后一个永恒的话题，关键是以何种方式显现。说红海市场，就拿NAT来说，就存在很多市场盲区，一样有得做。无论是红海，还是蓝海，关键是看你的期望值多少了。我们就是一只小蚂蚁，所以只要吃到一粒米，就能饱，呵呵。我们只能专心将自己的东西尽量做好，尽量让更多的人能够使用（无论是有钱的，还是没钱的），东西让别人用了，才能体现其社会价值，这才是真正有意思的地方。

89. shisco 于 2010-11-08 6:45 上午

    回silent：
    SP部署还是很有价值的，现在流行的smart pipe，monetization很多时候就是要用DPI，此外在国外很多大T如vodafone欧洲大部分国家GGSN的DPI都是打开的，针对Skype等应用

90. CC 于 2012-03-28 8:31 下午

    上海盖奇结合国内网络自身的特点，专门设计了基于Cavinum SE的专用DataPlane OS，开发了线速应用层协议识别及深度内容检测（Deep Packet Inspection）引擎，从多层次、多角度出发推出了TC8000、TC5000、TC3000等产品系列，可满足运营商、高校、城域网、大型数据中心用户10Gbps、20Gbps、40Gbps、80Gbps、100Gbps等各种流量控制需要。产品支持IPV4/IPV6双协议栈。

91. Panabit 于 2012-04-03 6:42 下午

    今天Google一下”Panabit”，突然发现，上面这鸟公司居然在Google购买了”Panabit”关键字了。我劝你们还是别购买了，前段时间也有一家同行做了同样的举措，现在都举步维艰了。这样不仅带不来明星效应，且浪费钱财，更让人鄙视！

92. 老韩 于 2012-04-04 12:04 下午

    看了楼上诸位评论，对上海盖奇很感兴趣。又看了他们官网，彻底被震撼了！从产品线和业务能力看，该司的规模和营收得多NB啊！

93. billy 于 2012-04-04 6:35 下午

    按其官网描述，启明、绿盟、山石等估计就只能为其提鞋拎包了…有小道消息称，位于携程对面的盖奇也”声称“一年有万台以上设备销售能力…请江湖里的销售兄弟们留意一下吧…

94. 王武 于 2012-04-04 7:21 下午

    回Panabit：
    我已同我们市场部网络营销人员核实，的确在谷歌Adwords广告中提交了与我们产品类似关键词（如：Panabit、Allot、Arbor Peakflow、Cisco SCE等）。关于91楼提到的Panabit关键词，我已令其下线。

95. Veteran 于 2012-04-04 7:27 下午

    回Panabit：
    我已同我们市场部网络营销人员核实，的确在谷歌Adwords广告中提交了与我们产品类似关键词（如：Panabit、Allot、Arbor Peakflow、Cisco SCE等）。关于91楼提到的Panabit关键词，我已令其下线。

96. TT 于 2012-04-04 7:51 下午

    其实也就是移植了freebsd 和Linux的内核协议栈而已,也没有什么!

97. Veteran 于 2012-04-04 8:02 下午

    回billy：
    关于一些未经确认的消息，欢迎各位业界前辈多来我司现场指正，我们有许多地方要向业界公司学习。各位大佬，有机会到上海，欢迎随时来我司做客。

98. Panabit 于 2012-04-04 8:02 下午

    回94楼：今天已经看到了。作为同行中的小蚂蚁，衷心祝愿你们做好！

99. 陈怀临 于 2012-04-04 8:52 下午

    王武贤弟，不错。值得交个朋友。

100. Veteran 于 2012-04-04 9:14 下午

     谢谢~陈首席关注!有机会到上海，欢迎陈首席莅临盖奇指导。

101. anonym 于 2012-04-04 10:59 下午

     to 100楼：

     http://www.gaiqinetworks.com/proSafe/20120306/67.html

     ”基于云平台的数据挖掘和行为感知“，此一类目中描述的众多引擎、特性引起了我的好奇心

     可否请解释一二，例如：

     智能分词技术——Q：分词训练的语料库的选择与机器学习的过程质量评估体系是如何建立的？

     非结构化数据多维分析引擎——Q：中文与英文最大的区别是什么？能否在引擎中得以体现？

     结构化数据多维分析引擎——Q：hadoop、hbase、GP等能否给出盖奇的评价？

     智能数据挖掘引擎——Q：是否”类规则化“的”批量“执行？逻辑如何控制？

     客户轮廓重组引擎——Q：”轮廓“是否等同于“画像”，轮廓定义的维度可细化到何种程度、应用场景的界定与复用如何实现？

     非结构化数据分析能力——Q：长文本与短文本、长微博与短微博的分析能力需求差异主要在哪些点上？

     非结构化数据的语义识别技术——Q：语义识别，分词、词性标注、关键词抽取、权重体系、语料库等的设计是否有可参考、可信的数据、实例展示出来？

     ps: 希望贵司工程师能够就上述问题加以解答，以释我心中之惑。性能方面的有Panabit、老韩等各路大侠，我小朋友一个，就是想多了解一下上述内容。多谢！

102. Veteran 于 2012-04-05 1:24 上午

     TO anonym&首席：
     这快目前主要是配合友商在做一些技术验证，借助自然语言处理框架GATE, ICTCLAS分词技术，整合Apache Hadoop、NoSQL Database等开源代码，离产品化还有一定的距离，anonym有好的建议或Idea欢迎莅临指导！

103. anonym 于 2012-04-05 2:06 上午

     to 102楼：

     “……借助自然语言处理框架GATE、ICTCLAS分词技术、整合Apache Hadoop、NoSQL Database等开源代码……”

     Apache Hadoop、NoSQL Database等有小吴总关注，我是门外汉，不敢妄谈。

     GATE框架窃以为只适用于学习与教学用途，缺乏大规模的商业验证，尤其是中文语言处理方面我所了解的此方面研究人员（与工程师）在学术研究（商业实践）方面，都是采用“基于papers自行编写程序代码的”模式来创建符合业务应用场景需求的基础处理框架，不知贵司是如何在网关上集成该框架的？数据的清洗、去重、预处理、半结构化->结构化等在网关上如何实现的？有何种数据支撑呢？

     ICTLAS分词技术历经逾10年积累，质量不可同日而语，这一点我是有信心的，好马配好鞍，ICTLAS是鞍，那么马贵司的好马在哪里饲养？

     窃还以为自然语言处理任何环节都具有很高的挑战性，分词、词性标注、命名实体因为较容易被用于解决问题，所以看上去容易一些，而句法分析、语义分析比较难于体现效果所以看上去难一些，但抛开这些不谈，窃以为：最高门槛是数据的获取，数据就是资源&命脉。

     贵司引擎所训练到的数据从何而来，数据的质量如何评价……等这些我此前提到的诸多关于数据本身的问题还是希望能够在不涉及商业秘密的前提下开放性的讨论一下。

     ps：输入法+搜索引擎就是“老树开新花”，没有细胞词库之类的出现更新之前，谁又能意识到这一点的巨大价值呢？

104. 老韩 于 2012-04-05 6:56 上午

     王总给个联系方式啊，昨天还听一个大型行业用户说起你们，给了个不错的评价

105. 千江映月 于 2012-04-05 7:37 上午

     panabit，应该是国内首家作“应用路由”的吧？现在好像不少厂商也跟进了，我在山石设备上有看到

106. Veteran 于 2012-04-05 6:53 下午

     M:15900595981
     E:Loongnetworks@gmail.com

107. 老韩 于 2012-04-06 3:11 上午

     @105
     根据产品测试时的印象，很难说清到底是谁先把“应用路由”功能做到设备里，只能说近两年这个功能需求比较火爆，Panabit是卖到这种场景中比较多的品牌之一。灵州和山石也都是加入比较早的，华赛稍晚一些。

108. anonym 于 2012-04-06 6:07 上午

     to 102楼：

     如果再纠结一下更细粒度的指标，不知贵司引擎的词性标注准确率能达到95%以上么？对于新词，如“犀利哥、凤姐”等之类的如何采集、训练与管理呢？语料库中是否在口头语与书面（官方）用语等类型上有所区分？在实际网关产品应用中能做到80%的准确率否？是类Siri模式还是其它的路线Roadmap呢？

     “桌上放了个苹果 vs. 苹果放在了桌上”

     是否可以用贵司的各种引擎跑一遍对上述简单语句的分析，输出结果贴在弯曲江湖供大家学习一下呢？

109. anonym 于 2012-04-06 6:11 上午

     楼上老是盗我id!

110. anonym 于 2012-04-08 6:07 上午

     to 楼上：
     我原本不知道重名该ID，最后一次用一下仅作道歉。

111. anonym 于 2012-04-08 6:16 上午

     to 楼上：
     没啊, 用感叹号只是觉得有意思, 要是喜欢你继续用吧. 反正只是个id而已

112. 新手0 于 2012-04-08 6:47 下午

     47楼的建议真是金玉良言！

     ==================================

     之前在x86 上做过包转发的性能优化；x86上linux内核包处理的主要有2个地方：
     1. 驱动层的buffer管理，收到1个包，进行1次buffer重分配，填充到dma ring desc,每发一个包，释放buffer内存到内核；
     2. linux内核协议栈对包的解析，会严重影响cache命中率；
     如果要实现自己的高性能包处理，建议直接hook驱动的收包，发包函数；完成自己实现；这样内核协议栈的问题，驱动实现的问题都可以避免掉

113. 新手0 于 2012-04-08 6:53 下午

     to 69，
     个人感觉，目前x86的纯转发性能不是太多问题(dpdk已经给出了一个很好的model)，问题在于session表的管理，动辄几百万的并发连接，cache miss和tlb miss的影响太大了，请问您有什么好的建议？

     ==================================

     目前来说，64字节是做不到8G线速的，目前能做到200字节左右8G线速，就是说，目前能做到500Wpps左右。但是这个测试数据是2544测试的结果。从实际应用看，由于会话数众多，会导致CACHE结果表现和测试仪测试时的表现不一样，所以一般只能打对折，也就是实际中可以维持在250Wpps左右的性能。

114. 理客 于 2012-04-09 4:05 下午

     新手0的数据和panabit的数据差距很大，可以和panabit切磋一下