《给力吧,x86》专题连载五:网络通信硬件平台巡览•G41篇

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享

子曰:工欲善其事,必先利其器。在上一期连载中,我们介绍了新兴的网络通信平台评估软件NCPBench。从本期开始,我们将陆续测试一批网络通信硬件平台,看看在优秀系统软件的支撑下,x86架构究竟有着怎样的性能,以及不同硬件配置对网络处理能力造成的影响。

价格不是最高也不是最低,规格不前卫但也不落伍,这就是G41,我们今天的主角,英特尔嵌入式产品线中在网络通信市场上拼杀的绝对主力。而它的载体,是台湾伯昇科技股份有限公司推出的一款网络通信硬件平台,代号NSP-1096。这款产品采用1U规格设计,前面板提供了6个千兆电口、2个USB 2.0接口和一个9针串口。接口左侧设有附带按钮的液晶屏,右侧空间则留给了扩展槽位。伯昇科技为NSP-1096准备了多种规格的扩展卡,用户可以用来为硬件平台添加多达4个千兆接口。

合理的配置与设计

打开NSP-1096的机箱上盖,可以看到处理器所在位置做了有针对性的设计。NSP-1096没有使用处理器散热风扇,而是采用了一个较大型的铜质散热器,通过特别制作的导流罩,配合机箱风扇形成一个专门风道,给CPU、内存条以及北桥芯片散热。风道两侧是磁盘悬挂位和电源,该产品配备了全汉的80Plus电源,让NSP-1096在所有的工作负载时间内都能维持较高的电能转换效率,降低了发热量以及其散热需求。

NSP-1096采用了专门为嵌入式平台设计的英特尔G41芯片组,和ICH7/ICH7R南桥芯片搭配使用。作为系统的核心,G41连接着处理器、内存和PCIe总线。它支持1333MT/s的FSB,可以兼容嵌入式产品列表内LGA775接口的各种赛扬、酷睿处理器;内存规格则支持到DDR2-800和DDR3-1333,且拥有两个内存通道,最大容量达到8GB。I/O方面,G41提供了16个PCIe v1.1信道,可以配置为1×16或者2×8;此外,通过DMI 1.0总线和G41连接的ICH7R南桥还能提供6个PCIe v1.0a信道。在NSP-1096上,这6个信道连接了6颗英特尔82754L网络芯片(对应前置接口,其中2组支持硬件ByPass);G41提供的PCIe v1.1 x16则连接到扩展槽位,用以连接使用了82576、82580等中高端网络控制器的扩展模块。

NSP-1096内置的6颗82574L芯片是沿用已久的嵌入式/服务器千兆以太网控制器,支持2个TX/RX队列和2个RSS队列,是一个成熟稳定、性能尚佳的产品。该芯片使用PCIe v1.1 x1接口,能支持MSI-X等技术。不过由于连接在支持PCIe v1.0a的ICH7R上,它仅能使用传统的MSI模式。扩展模块上应用较多的82580则是英特尔最新推出的单芯片四网口千兆以太网控制器,采用了支持5GT/s速率的PCIe v2.1 x4接口,支持包括LTR、TPH、DCA等在内的诸多特性。面向网络通信、主流服务器和高密度刀片的82580是十分强大的芯片,其规格甚至比上一代的王者82576还要强一些。

测试使用的这台NSP-1096还配备了一颗主频为2.66GHz的英特尔Q9400处理器,该处理器使用45nm工艺设计制造,具有4个核心和6MB二级缓存。内存使用了2根DDR3-1333规格、1GB容量的产品,工作在双通道模式。网络接口方面,除了板载的6个千兆铜口,我们还在扩展槽位安装了一块编号为BEM-580-F4的扩展卡。该卡使用了一颗英特尔82580网络控制器,提供4个额外的SFP接口。不过,理论上该芯片在连接到G41的PCIe v1.1后速率将降为2.5GT/s,功能特性也只有包括MSI-X模式在内的v1.1部分可以使用。

整体性能超越预期

在CF卡中安装了NCPBench 0.8后,我们将每两个相邻接口配置为桥模式,进行纯转发性能与带简单业务情况时的测试(NCPBench的功能介绍和使用方法见上一期连载内容)。对于NSP-1096来说,BEM-580-F4扩展模块在很大程度上左右着整机的处理能力,我们也对其进行了重点考察。考虑到是第一次在这样的配置场景中进行测试,每个项目在使用测试仪表进行测试后,都再使用NCPBench进行一次自测试。我们可以对比两组数据的差异,用以评估NCPBench测试结果的准确性。

从测试结果中可以看出,当NCPBench运行在纯转发模式时,BEM-580-F4扩展模块上的4个接口转发64Byte帧的速率超过4Mpps,其他帧长时均接近或达到线速。这个结果虽然出色,却使人略感遗憾。我们曾经在一台采用5520芯片组的硬件平台上,测得过82580的4个接口间所有帧长均线速转发的结果,也就是说瓶颈不在网络控制器。而对NSP-1096全部10个千兆接口的测试结果表明,该产品对64Byte帧的整机转发能力接近9Mpps,这又意味着,之前测试中的性能瓶颈也不应该在处理器。经过排除分析,我们推测问题很可能来自I/O方面,理论上G41与82580协商后只能使用PCIe v1.1规格进行连接,在传输速率和效率上都大打折扣。此外,硬件平台在缓存和内存等方面的差异,也可能会对数据包转发能力造成一定影响。不过总体来说,NSP-1096的设计已经最大地发挥了G41芯片组的潜能,表现出来的整体性能也超越预期,足以满足其目标市场的需求。

本次测试中,测试仪与NCPBench得到的两组结果保持高度一致,我们只在高负载情况下观察到pps统计数值略有不同,没有出现往常几个百分点级别的差异;加载简单业务后,性能数据也没有发生很大变化,只在使用128Byte帧长测试时有所降低。我们认为,造成这两种情况的主要原因是处理器本身有性能余量,接口带宽也限制了极限数据的出现。单就NCPBench来说,其自测试结果还是比较准确的,可以满足用户的常规测试需求。

测试项·配置

帧长度

转发

(100%=4Gbps)

转发+业务

(100%=4Gbps)

测试仪 NCPBench 测试仪 NCPBench
64 Byte 67.773% 67.773% 67.773% 67.773%
128 Byte 96.143% 96.143% 93.707% 93.707%
256 Byte 100% 100% 100% 100%
512 Byte 100% 100% 100% 100%
1024 Byte 100% 100% 100% 100%
1280 Byte 100% 100% 100% 100%
1518 Byte 100% 100% 100% 100%

表格:NSP-1096吞吐量测试结果(针对BEM-580-F4扩展模块)

(3个打分, 平均:2.33 / 5)

系统软件工程师实战攻略(体系结构篇)--(1)

前言

这个世界上,需要玩虚的;也需要玩实的;
活命需要玩实的。但不一定活的好;不一定活的开心;但可以活下去。
最高境界是玩虚的;但前提是银行帐号里银子要是实在的。。。
《系统软件工程师实战攻略(体系结构篇)》 的目的为嵌入式系统工程师,网络工程师,提供一些体系结构实战案例。目的是活命。所有的代码都是实践调试过的,具有产品级别的质量。版权是BSD License。换言之,随便重用。
这些东东对大辽,大宋的工程师们,烟酒生们都适用。
以后再整《系统软件工程师实战攻略(操作系统篇)》和《系统软件工程师实战攻略(网络篇)》
然后就封笔了。
希望有所帮助,
陈怀临,2011 12 8 ,加州
如何做一个交叉编译器(cross compiler)和工具链

要玩嵌入式,玩CPU和板子,首先要学会定制一个交叉编译器。交叉编译器是啥意思呢? 其实就是在你的研发的机器上(例如一个x86机器),做研发,写代码。然后用这个编译器去产生相应的代码(例如,MIPS,Arm,或者PowerPC,或者龙芯。。。。。。)
GCC和ToolChain包括gcc,gdb,tools三大块。源码都可以从GNU去下载。然后自己修改和定做。
相关的下载地址为:
GCC: http://gcc.gnu.org/releases.html
GDB: http://www.gnu.org/s/gdb/download/
binutil:http://www.gnu.org/software/binutils/
libc: http://sourceware.org/newlib/
下面是一个完整的script可以用来做MIPS,PowerPC,ARM和任何其他目标CPU的cross compiler。我做的这些东东是2004年做和整理的。可以看见各种版本与目前最新的偏低了。

/*
* Copyright (c) 2011, Huailin Chen
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*    notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*    notice, this list of conditions and the following disclaimer in the
*    documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
*    must display the following acknowledgement:
*      This product includes software developed by
*      the Huailin Chen and its contributors.
* 4. Neither the name of the Huailin Chen nor the names of its
*    contributors may be used to endorse or promote products derived from
*    this software without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS “AS IS” AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
* Creation Date: 1/14/2004
* Author: Huailin Chen huailin@gmail.com
*
* $Id: build_script,v 1.1 2004/05/07 17:41:48 huailin Exp $
*/

########################################
PWD =
CPU =
########################################
#把下载的各个package展开后放在一个gnu_download目录里
#4个子目录,分别存放gcc,gdb,libc和binutil的原文件
BINUTILS_DIR =./gnu_download/binutils-2.9.1
GCC_DIR =./gnu_download/gcc-2.95.1
LIBC_DIR =./gnu_download/newlib-1.8.2
GDB_DIR =./gnu_download/gdb-5.0
###################################
TARGET_ARM =arm-elf
TARGET_MIPS_ELF=mips-elf
TARGET_PPC_EABI_ELF=powerpc-eabi
TARGET_SH_ELF =arm-elf
#TARGET_AMD
#TARGET_ALPHA
#TARGET_IA32
###################################
#PREFIX目录是最后的结果存放目录。要事先建好
#
PREFIX=$(PWD)/../arch/$(CPU)/tool-chain
TARGET = $(TARGET_ARM)
####################################
mkdir build-binutils build-gcc build-newlib build-gdb
cd build-binutils
$(BINUTILS_DIR)/configure –target=$(TARGET) –prefix=$(PREFIX) -v
make all install
pwd
# Configure, build and install gcc
cd build-gcc
$(GCC_DIR)/configure –target=$(TARGET) –prefix=$(PREFIX) –with-newlib  –with-headers=$(PWD)/gnu_download/$(LIBC)/newlib/libc/include –with-gnu-as –with-gnu-ld –enable-languages=”c”
-v
make all install
#Configure, build and install libc
pwd
cd ../build-newlib
$(LIBC_DIR)/configure –target=$(TARGET) –prefix=$(PREFIX) -v
make all install
#Configure, build and install gdb
pwd
cd ../build-gdb
$(GDB_DIR)/configure –target=$(TARGET) –prefix=$(PREFIX) -v
make all install
#Clear history directory/files
pwd
cd ..
rm -rf build-*
(4个打分, 平均:4.00 / 5)

2011年中国科学院院士增选当选院士名单

2011年中国科学院院士增选当选院士名单

(共51人,分学部按姓氏笔画为序)
数学物理学部(9人)
序号
姓名
年龄
专业
工作单位
1
王广厚
71
原子分子与团簇物理
南京大学
2
张维岩
55
激光聚变与等离子体物理、理论物理
中国工程物理研究院
3
张肇西
70
粒子物理理论
中国科学院理论物理研究所
4
陈永川
47
应用数学
南开大学
5
武向平
50
天体物理
中国科学院国家天文台
6
袁亚湘
51
运筹学
中国科学院数学与系统科学研究院
7
高鸿钧
47
凝聚态物理
中国科学院物理研究所
8
鄂维南
47
数学
北京大学、普林斯顿大学
9
潘建伟
41
量子信息、原子分子与光物理
中国科学技术大学

化学部(7人)
序号
姓名
年龄
专业
工作单位
1
田 禾
48
精细化工
华东理工大学
2
刘忠范
48
物理化学
北京大学
3
严纯华
50
无机化学
北京大学
4
张俐娜
(女)
70
天然高分子与高分子物理
武汉大学
5
李亚栋
46
无机化学
清华大学
6
杨学明
48
物理化学
中国科学院大连化学物理研究所
7
赵进才
50
环境化学
中国科学院化学研究所

生命科学和医学学部(9人)
序号
姓名
年龄
专业
工作单位
1
朱玉贤
55
植物生理学
北京大学
2
张学敏
47
医学
军事医学科学院
3
张明杰
44
结构生物学
香港科技大学
4
李 林
50
生物化学与分子生物学
中国科学院上海生命科学研究院
5
赵玉沛
56
外科学(普通外科)
北京协和医院
6
康 乐
52
昆虫学
中国科学院动物研究所
7
黄路生
46
动物遗传育种与繁殖
江西农业大学
8
舒红兵
44
细胞生物学
武汉大学
9
葛均波
48
心血管内科
复旦大学

地学部(10人)
序号
姓名
年龄
专业
单位
1
万卫星
52
空间物理
中国科学院地质与地球物理研究所
2
石广玉
68
大气物理
中国科学院大气物理研究所
3
刘丛强
55
地表地球化学
中国科学院地球化学研究所
4
周忠和
46
古生物学
中国科学院古脊椎动物与古人类研究所
5
郭华东
60
遥感科学与应用
中国科学院对地观测与数字地球科学中心
6
高 山
49
地球化学
中国地质大学(武汉)
7
龚健雅
54
测绘科学与技术
武汉大学
8
傅伯杰
53
自然地理学、景观生态学
中国科学院生态环境研究中心
9
焦念志
48
生物海洋学
厦门大学
10
舒德干
65
古生物学及进化生物学
西北大学

信息技术科学部(7人)
序号
姓名
年龄
专业
工作单位
1
李树深
48
半导体器件物理
中国科学院半导体研究所
2
杨学军
48
计算机体系结构与系统软件
国防科学技术大学
3
郑建华
54
密码学
中国人民解放军保密委员会技术安全研究所
4
金亚秋
64
电磁散射与空间遥感信息
复旦大学
5
徐宗本
56
智能信息处理
西安交通大学
6
梅 宏
48
计算机软件
北京大学
7
黄 维
48
有机光电子学
南京邮电大学

技术科学部(9人)
序号
姓名
年龄
专业
工作单位
1
朱 荻
57
机械制造及其自动化
南京航空航天大学
2
张统一
61
力学
香港科技大学
3
沈保根
58
磁性材料
中国科学院物理研究所
4
郑 平
75
工程热物理
上海交通大学
5
南策文
48
复合材料
清华大学
6
赖远明
48
土木工程(寒区工程)
中国科学院寒区旱区环境与工程研究所
7
翟婉明
47
载运工具运用工程
西南交通大学
8
雒建斌
49
机械设计及理论
清华大学
9
魏炳波
47
材料科学与工程
西北工业大学

2011年当选中国科学院外籍院士名单
(共9人,分学科领域按姓氏音序为序)
序号
姓名
年龄
国籍
专 业
工作单位
1
戴维•格罗斯
David Gross
70
美国
理论物理
美国加州大学圣巴巴拉分校
2
弗朗斯瓦•马蒂
Francois Mathey
70
法国
化学
中国郑州大学
新加坡南洋理工大学
3
野依良治
Ryoji Noyori
73
日本
有机化学
日本独立行政法人理化学研究所
4
阿夫拉姆•赫什科
Avram Hershko
74
以色列
生物化学
以色列理工学院
5
蒲慕明
Muming Poo
63
美国
神经生物学
中国科学院神经科学研究所
美国加州大学伯克利分校
6
罗伯塔•鲁德尼克(女)Roberta L. Rudnick
53
美国
地质学-地球化学
美国马里兰大学
7
刘必治
Bede Liu
77
美国
信息处理
美国普林斯顿大学
8
饭岛澄男
Sumio Iijima
72
日本
纳米科学
日本名古屋名城大学
9
罗格•欧文
D. Roger J. Owen
69
英国
计算力学与工程
英国斯旺西大学
(2个打分, 平均:3.00 / 5)

2011 。中国工程学院 。院士

(1个打分, 平均:1.00 / 5)

《给力吧,x86》专题连载四:网络通信平台评估软件NCPBench应用分析

x86网络通信硬件平台的迅猛发展,已经吸引了许多厂商、用户的关注。在进行评估测试时,如何才能准确、便捷地了解硬件平台的整体性能,是所有人都关心的问题。本期,就让我们聚焦于新兴的评估软件NCPBench,感受一下它诸多与众不同的特性。

在上一期连载中,我们介绍了与北京市某学校信息中心合作进行的一次硬件平台选型测试,并以此为依据,证实了x86平台在网络业务处理方面的潜力。随后一段时间内,我们收到了许多来自厂商、用户的咨询;个别用户甚至愿意提供更完善的环境,希望我们将这一系列测试长期进行下去,持续公开更详细的测试结果。对于来自读者的热情关注,我们表示感谢,并将在后续连载中安排更多平台的测试分析。同时,我们也在这里介绍一款经常使用的网络通信平台评估软件NCPBench,供读者进行独立的性能评估。

以互联网的名义

NCPBench是近期兴起的一款测试软件,用于评估x86硬件平台做网络业务处理时的性能。在我们看来,该软件融入了大量的互联网基因,与日常使用的诸多软硬件评估产品有着明显的不同。众所周知,用户参与是互联网产品成功的基本要素,NCPBench显然抓住了这个要点,在产品发展的方向性上与用户需求保持着高度一致。该软件采用了十分开放的构建模式,版本升级比较迅速。与之对应的,在主要功能保持稳定的情况下,再根据用户反馈需求的迫切性,逐步完善产品的细节功能。而互动的效果则取决于用户数量与质量,所以NCPBench本着“让更多人使用”的理念,采用了免费的许可授权模式,允许甚至鼓励被用于包括商业在内的各类评估环境。

NCPBench与其他软硬件评估产品的第二个不同,体现在操作的便捷性方面。一般来说,网络通信、信息安全等领域的测试解决方案都比较复杂,使用时需要较高的专业素养,配置过程也相对麻烦。NCPBench则很好地简化了用户端的工作,使用时只需对网络接口、业务模式等几个必要环节进行设置,即可进行性能测试。一键式安装也是非常实用的功能,我们拿到新的硬件平台,用几分钟时间就可以将NCPBench安装到本地或USB存储设备上,而不必经历从磁盘分区到编译的诸多步骤。该软件还内置了常见的硬件驱动,在多数平台上可以直接发挥出硬件的所有潜力。

利用NCPBench,我们可以评估任何x86平台的网络业务处理能力。现阶段该软件提供了“转发”与“业务”两种应用模型,前者不对数据包进行任何处理,考察的是硬件平台的数据包转发极限;后者将建立数据流的概念,其业务复杂度与NAT、状态检测引擎类似。通常,我们会测试x86硬件平台在两种模型下的吞吐量与延迟,当然这些结果都是理论值,仅供评估参考。根据经验来看,设备在真实流量下的综合效能,如果能达到模拟测试环境中的50%,就已经相当难得了。不过“转发”模型下的性能还是很重要的,毕竟对于没有任何加速逻辑的x86平台来说,数据包纯转发的性能是一个极限标杆。没有高性能转发做支撑,任何上层业务都将是纸上谈兵。

高性能的诱惑

众所周知,目前x86平台用做网络业务处理时,首先要解决的就是多个处理器内核间的调度与资源分配问题。如果使用传统的处理模型,很可能导致资源使用的不平衡,无法发挥出硬件平台的整体性能;而多核并行处理的模式,虽然在理论上可以提升性能,实际使用时的效果却大多难令人满意。NCPBench在这方面就显得非常灵活,用户可以人为设定用做转发及业务处理的内核数量,并且转发与业务在每个独立内核上也都是并行处理,系统呈纯SMP形态。该软件也不像某些同类产品那样必须人为地将网络接口与处理器内核进行绑定,而是根据硬件平台配备的接口种类及数量,自动建立关联关系。

经过多次测试,我们已经确认NCPBench在x86平台上可以做到非常强悍的数据包转发性能。现有测试数据中,64byte UDP数据包的最大转发速率接近30Mpps,是在英特尔Sandy Bridge搭配i82599万兆网卡的平台下测得。此时使用RFC 2544规定的7种帧长的数据包测试转发延迟,时间也均在10微秒以内。这意味着,x86平台用做20G/40G环境中的业务处理,并非是遥不可及的目标。需要注意的是,x86平台所能达到的的数据包转发能力与处理器、桥片、网卡芯片等都有很大关系,如果在硬件规格上无法很好地匹配,性能瓶颈就会过早地出现。我们发现,网络通信硬件平台大多经过有针对性的定制,硬件搭配相对合理;服务器的配置则大多是计算远强于网络,很可能要另行采用高性能网卡以达到更快的转发速度。

为了让用户更方便地了解x86硬件平台的网络处理性能,NCPBench还内置了一个自评估工具。该工具的使用极其简单,只需用网线将要测试的接口两两互联,就可以在环路内生成指定帧长、方向、强度的UDP测试流量,对硬件平台自身进行测试。我们注意到,在多数情况下,使用自评估工具得到的性能值都较测试仪得到的略低,但观察到的最大一次误差也仅在3%以内,还是具有比较强的参考价值。

(2个打分, 平均:2.50 / 5)

《给力吧,x86》专题连载三:x86平台网络应用效能实测

弯曲评论现在的影响力很大,甚至能吸引到一些行业用户的关注(潜水居多)。本文就是《给力吧,x86(1)——11月10日测试记录》一文刊登后,用户直接与我们沟通进行的一次测试合作的副产品。这是一个良好的开端,后续还有与其他用户联合进行的更大、更深入、更给力的测试,敬请关注。

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

前两期连载中,我们简单回顾了x86平台在网络产品中的应用历程,又逐一分析了其面向不同用户群体的硬件供应模式。实践是检验真理的唯一标准,本期就让我们走进现实中,借助近期的一次测试,看看在网络技术及应用高速发展的今天,x86平台对业务的承载能力究竟如何。

虽然一些业内人士已经看到x86平台的发展,认为其将在网络领域有所斩获,但对于普通用户来说,再次接受x86平台有着很大的难度。一方面,这个曾经不太适合做网络业务处理的硬件平台为许多用户留下过不好的应用体验;另一方面,一些厂商长期对x86架构并不客观的宣导,也加深了其在用户心中的负面印象。

先入为主的误会

我们在之前的调研中发现,抱有这种看法的用户并不在少数。北京市某学校信息中心负责人李老师就是一个典型代表,虽然他在目前进行的流控产品选型中比较中意连续两年获得计算机世界年度产品奖的Panabit应用层流量管理系统,却因其运行在x86平台上而犹豫不决。

“我们一直用着一台x86架构的UTM产品,效果越来越不好。”李老师介绍说,“以前网络负载不大时,设备运行没有任何问题;现在越来越多的教学、科研任务要通过网络进行,学校网络出口的百兆带宽经常被占满,UTM运行也变得不稳定。”令人没有想到的是,他紧接着又说出一个令我们很难理解的结论,“看来,x86平台也就是这个样子了。”

x86架构与网络运行不稳定有直接关系?实验室工程师习惯以量化的数据去看待问题,自然无法认同李老师的推断。在他的协助下,我们走进该校信息中心,对网络运行情况进行了实地考察。经过分析,我们发现造成学校网络出口拥塞的主要原因大致有三:其一是在线课件播放系统产生的数据流量,由于学生分布在不同校区,远程教学会在上课时段对网络造成比较大的压力。其二是学校周边视频监控的数据上传流量,根据教委要求,为加强校园安全工作,各学校的视频监控数据需实时汇总到教委信息中心,以便对突发事件做到事前预警、事中监控及事后取证。李老师所在的学校需要实时上传4路监控视频,这也是该校网络上行带宽占用率居高不下的原因之一。其三则是P2P、在线视频等非业务应用产生的流量,此类应用会无限制地占用网络带宽,是每一个网络管理员都非常头疼的问题。我们在分析报表中看到,以迅雷为代表的下载应用在网络使用高峰期一度抢占了70%左右的带宽,严重影响了该校教学工作的正常开展。

根据分析得到的数据,我们建议李老师对UTM上的安全策略进行了调整,不再对远程教学与视频监控相关的流量进行应用层面的安全防护。由于它们都是可信流量,修改过的访问控制策略非但不会造成安全隐患,还能有效降低UTM的负载。很快,我们看到设备的CPU占用率显著下降,内网用户访问网络的延迟也回到相对合理的水平,x86“不行”的误会也就此得到解除。但对于非业务流量的控制需求,该校主出口使用的这台国外某品牌的UTM产品并没有足够的本土化保障,对国内主流应用的支持力度相对薄弱,无法进行有效的控制。可以说,流控产品的部署势在必行。

标前测试:大放异彩

虽然解决了UTM运行不稳定的问题,李老师所在的信息中心管理团队还是对x86架构产品存有疑虑,不愿直接将设备接入实际环境进行测试。这一点大家都能理解,毕竟学校网络承担着大量的教学、科研任务,万一出现意外,后果将不堪设想。在我们看来,李老师所在团队目前所需要的,是一次客观、严谨的标前测试。实际上,这一环节已经被国内越来越多的用户所认可,因为是否选购产品,或者是否再接入实际环境测试,都可以用标前测试得到的量化数据作为决策依据。

在实验室合作伙伴思博伦通信的支持下,我们与李老师所在团队合作,于近日测试了他们关注的Panabit应用层流量管理系统。该产品运行在x86平台上,拥有优秀的协议识别率及性能。商务模式方面,Panabit可以通过软件授权或服务的形式进行交付,给用户自行选择硬件的自由,还可以节省大量开支。李老师这次带来的硬件,就是供应商基于该校网络实际情况,推荐的一款带有6个千兆电口的基于Atom N270的x86网络通信硬件平台。

Atom N270?实验室工程师们感到难以置信。要知道,流控引擎是在DPI(Deep Packet Inspection,深度包检测)的基础上结合多种技术发展而来,属于处理模型相对复杂的一类业务应用,对硬件平台的计算能力有着相当高的要求。而Atom N270是什么级别的产品?放在上网本里也算是两代之前的配置了,它真能满足百兆级别应用层流量管理的需求?

诸多疑问化作动力,催使我们立即开始了测试。被测设备预装了Panabit 10.10专业版,开启了应用层流量分析,作用于4个千兆口绑定成的两组桥。根据联合制定的测试方案,我们首先对带业务情况下的吞吐量、延迟进行了测试。虽然常用的UDP测试流量对于IPS、WAF等应用层安全设备来说意义不大,对流控产品测试却有着十分现实的意义——据统计,目前互联网中占流量比例最大的是在线视频应用(在教育、网吧等行业中比例数字更为惊人),它们其中大多数都使用了UDP传输,且数据包偏小。测试结果令人震惊,当我们单独测试1组桥的性能时,该平台64Byte帧的吞吐量达到41%,也就是800多兆的处理能力。当帧长逐渐增加时,吞吐量也呈线性增长,并在1518Byte时达到线速。此时最大的平均延迟,也仅为68微秒。而在同时对2组桥的测试中,设备的整体吞吐量又有所增加,在256Byte时就已拥有接近2G的性能。我们也利用全部4个接口测试了该产品的链接处理能力,当链接的Timeout时间设为0时,Avalanche测得的稳定值在90000左右,峰值为90014CPS(HTTP)。这一次的数据体现出了设备的极限性能,根据以往经验,其表现完全可以胜任普通千兆接入环境中的应用。

测试项·配置

帧长度

2个GE做1组桥

(100%=2Gbps)

4个GE做2组桥

(100%=4Gbps)

吞吐 平均延迟 吞吐 平均延迟
64 Byte 41.19% 24 us 22.28% 34 us
128 Byte 54.42% 24 us 37.37% 38 us
256 Byte 67.65% 24 us 48.08% 42 us
512 Byte 82.10% 37 us 52.35% 42 us
1024 Byte 92.02% 76 us 53.38% 54 us
1280 Byte 95.58% 64 us 55.37% 58 us
1518 Byte 100% 68 us 56.92% 68 us

有了这些测试数据,老师们基本放下心来,将设备接入实际环境中进行了长时间的测试。对于流控设备上线后的效果,李老师给予了充分的肯定:“业务流量控制住了,学校网络出口的流量也就下来了,UTM的负载就更小了。”而在稳定性方面,他也坦言没有遇到过任何异常情况,不过我们仍然建议做更长时间的测试,以便进一步考察x86网络通信硬件平台长期不间断运行的效果。

后记:广阔天地 大有作为

从测试结果中可以看出,x86平台的网络业务处理能力确实有了长足的进步。目前,在英特尔面向网络应用的嵌入式产品线中,Atom N270是最低端的一款产品,都有着如此强大的处理能力。随着网络通信和信息安全业务的关注点逐步向应用层迁移,x86平台的优势将会越来越明显。当然,现有基于x86架构的产品仍不足以在高端市场和基于专用网络通信处理平台的产品竞争,但在其他诸多领域内,x86已经表现出了一定的竞争力。对开源系统良好的支持、海量的软件资源、较低的开发难度、价格优势和易获取性,这些都是其取胜的砝码。是否有点眼熟?没错,如果哪天基于x86架构的网络通信和信息安全产品(至少是中低端)开始山寨化,大可不必感到奇怪。

(1个打分, 平均:5.00 / 5)

《给力吧,x86》专题连载二:x86平台在网络领域的发展应用分析

上一期,我们系统地回顾了x86平台在网络产品中的应用历程,得出了其目前处于高速发展中的结论。越来越多的设备制造商也认识到这一点,开始在产品的研发中考虑x86平台。那么,自主研发硬件与定制网络通信硬件平台,究竟哪条路更适合设备制造商?x86服务器缘何又受到最终用户的青睐?

得不偿失的自主研发

自主研发是产品核心竞争力的基础,网络领域也不例外。对于网络设备的硬件部分来说,自主研发意味着差异化、定制化和成本的可控性。这既可以与业务高度匹配,又能取得技术、规格与价格上的优势,是每个厂商都梦寐以求的局面。

但真要做到全部自主研发,却也未必就是好的选择,甚至不太可能。自主研发需要投入大量人力物力,且有着相对较长的时间周期,这是大量初创企业乃至市场规模较小的安全厂商很难接受的。如果自主研发的硬件平台存在瑕疵,其代价将更为惨重,厂商损失的不再只是前期投入,而是转瞬即逝的市场机会。所以,通常只有通信行业的巨头才会去押宝硬件平台的自主研发,更多地体现技术上的壁垒,且在预研阶段不会拘泥于某种特定的方案。

此外,x86平台一些不可磨灭的消费类特性,也是阻碍网络设备制造商实现自主研发的关键因素。虽然嵌入式范畴内的x86平台也拥有了较长的生命周期,CPU、桥片、网络控制器的种类却偏多,更新换代的速度又比较快,且不同时代、不同桥片对应的CPU针脚都不是100%兼容。相信没有一个网络设备制造商可以跟得上这种更新速度,我们在长期的测试工作中,也确实没有见到过哪款通信或安全产品是采用自主研发的x86平台(少量定制型号与CheckPoint除外)。大家共同的选择,还是定制化服务器或由工控机衍生而来的x86网络通信硬件平台。

服务器:近水楼台先得月

既然x86平台以通用性为主打,那么注定其在市场等非技术层面更具竞争力。以服务器为例,采用x86体系架构的产品在价格、性能和易获取性方面都有着明显优势,占据了绝对主流的市场地位。近几年来,x86架构服务器在网络处理能力和I/O特性方面有着显著提升,标配4个千兆网口的产品也屡见不鲜。更有甚者,一贯拥有良好前瞻性的英特尔将于今年发布标配2个万兆网口的新服务器平台,会将网络应用效能提升到一个新的高度。

基于以上多种原因,越来越多具有一定研发能力的用户开始采用唾手可得的x86服务器来打造适合自身应用的网络设备。尤其在电信、金融、教育等行业,用户业务本身存在比较强的定制化需求,性能要求又相对较高,故此类情况时有发生。在我们的调研中,就出现了一些具有代表性的案例。上海交通大学网络信息中心的姜开达老师曾坦言,两年前该校在对校园网出口入侵检测系统的选型中,就遇到了市售产品难以满足需求的窘况。在充分分析了业务需求的前提下,姜老师选择了带领团队自行研发的方式,以多组x86服务器分布式处理的方式实现了对万兆链路的实时监测。这一举动,不仅构建了一个开放的、可以承载多业务的科研平台,更将科研成果转化为实际的安全服务,为校园网的稳定运行提供了保障。

许多数据都表明,面向网络应用的x86硬件平台的市场需求处于不断扩大的阶段,而服务器因其易获取性成为了用户的首选。网络产品本身也有着互联网化的倾向,以软件授权、服务为代表的商业模式剥离了传统软硬件一体化的产品形态,开始赋予用户自行选择硬件平台的权利。来自学术界的激进看法甚至认为,未来无论互联网还是数据中心,都将只由交换机和服务器两种硬件产品构成。

工控机的反击

x86服务器在网络领域的无心插柳,也刺激了传统的网络通信硬件平台提供商。他们开始推出有针对性的产品及商业模式,直接面向最终用户。我们在调研中发现,原本对新硬件方案不甚敏感的他们也逐步加速产品研发流程,主动接纳较新的x86平台,积极拓展产品线。对于用户在存储子系统方面比较普遍的应用需求,许多网络通信硬件平台提供商也开始在产品中增加硬盘位及相应的RAID特性。某些厂商还针对x86平台在硬件狗等方面的先天不足,以板载CPLD芯片等方式实现了强大的监控与联动能力。用户及设备制造商可以通过软件接口读取、调用这些功能,甚至基于CPLD自行开发其他监控手段,增强x86平台的可靠性。

与服务器相比,网络通信硬件平台有着一些无法被超越的优势。首先,它从内到外都可以由用户深度定制,无论是接口种类或数量,CPU、网络控制器的型号,还是PCB的板型及工艺,机箱规格及面板设计,都可以根据设备实现的业务进行最合理化的搭配。这种裁剪还降低了整机成本,也减小了系统功耗及散热难度。其次,可靠性在网络通信硬件平台的设计中至高无上,诸如网口的硬件Bypass等特性是绝大多数服务器产品无法提供的。而在元器件规格方面,多数网络通信硬件平台也都采用了比服务器更专业化、寿命更长、对工作环境要求更宽松的产品,使系统的稳定性有了更多的保障。虽然这一切都增加着硬件整体成本,所改善的却是网络产品必须具备的特性。所以,虽然销量巨大的服务器有着相对低廉的价格,但标准化的产品形态和对网络业务并不十分友好的支持,都使其在短时间内无法替代x86网络通信硬件平台。在网络通信硬件平台提供商逐步走向前端的今天,用户不妨在选型时也多给予一些关注。

(2个打分, 平均:5.00 / 5)

单芯片的云计算:Intel . 众核 . KnightCorner . 50+ Core . 22nm

单芯片, 50+ x86+SIMD extension的核,22nm工艺;计算能力为1 Teraflop。不知Tilera的同学们如何想。当然,KnightCorner的市场方向主要还是SuperComputing或者HPC。单芯片的高性能计算。太可怕了。。。

关于Intel这方面项目的背景可以参阅:Intel MIC(Intel Many Integrated Core Architecture)。


(1个打分, 平均:5.00 / 5)

《给力吧,x86》专题连载一:x86平台在网络产品中的应用回顾

曾经在弯曲上发过两篇关于x86硬件平台的性能测试报告,还煞有介事地起了个《给力吧,x86》的专题名。后来决定将此内容扩大化、正规化,便专注于平面媒体的发布。直至今日,本专题已陆续连载了9期,从产业、产品、应用等方面比较完整地介绍了x86平台的现状,现整理发布于弯曲评论。专题的制作过程中,得到了很多朋友、同事鼎力协助,在此一并表示感谢。未来希望还能有机会把专题延续下去。

本专题内容原文刊登于《计算机世界》。水平有限,文中定有偏颇之处,希望弯曲网友不吝赐教。

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

x86,通用市场的王者,却在网络产品领域背负着诸多骂名。在与厂商、用户的交流中,计算机世界实验室的工程师多次听到“落后的产品架构”、“性能方面有致命缺陷”之类的评语。这些说法有无偏颇?x86平台是否真的不堪一用?本期开始,我们将通过技术分析与实际测试的手段,以专题连载的形式对x86平台用做网络处理时的性能进行细致的评估,努力梳理出一个客观的结论。

微博上流传着这样一则关于IT的冷笑话:“世界是你们的,也是我们的,但最终还是x86的。”的确,以英特尔、AMD为代表的x86阵营在通用市场长期占据着压倒性的优势,给许多用户留下了“电脑就是x86”的概念。而在相对封闭的网络产品领域,x86则远没有这么风光。此类设备要求硬件平台拥有高速I/O、对专有业务的加速能力和极高的可靠性,这些恰恰都不是x86的强项。所以,虽然x86平台在网络产品诞生之日起就在其中占据了一席之地,却一直处于非主流的地位。

不进则退

应该说,x86平台与网络产品结缘,开篇还是很美好的。在那个骨干网尚不如今天小区宽带接入速度快的时候,x86平台的网络处理能力完全可以满足要求。那个时候的x86 CPU和套片也没有如今恐怖的功耗和发热量,稳定性与PowerPC、MIPS架构的SoC平台在伯仲之间。真正有说服力的还是工业界对x86平台的广泛认同,作为当时的标志性产品,思科的PIX系列防火墙在网络安全发展史上有着很高的地位。即便是今天,在一些环境下依然能看到它的身影,可谓久经考验。

随着互联网技术的高速发展,网络产品很快遭遇性能瓶颈。不管是路由器还是防火墙,都面临着提升转发能力的迫切需求。恰恰在这个时候,x86开始了在通用领域的急速扩张,将性能改善的重点放在个人计算、企业计算乃至数字娱乐等方面,并不热衷于(也没有必要)对总线、I/O等方面进行有针对性的设计。在这种情况下,网络设备制造商开始尝试采用专用芯片对转发流程进行加速,通用处理器则只负责路由计算与查找、状态检测等计算密集型任务。这种做法虽然很好地解决了性能瓶颈,但在研发难度、制造成本方面的门槛却也相当高。为了满足市场需求,英特尔和IBM先后发布了被称为网络处理器(NP)的一系列产品。它们针对网络应用而设计,采用非x86内核+微引擎的设计思路,具有很高的转发性能和一定的编程能力,受到工业界的热捧。也正是因为它们的出现,使得孤木难支的x86平台与网络产品渐行渐远。

英特尔:史上最强亲友团

待到x86再次回归,已是近几年的事了。这次的需求主要来自信息安全领域,随着安全防护的重点由网络层向应用层迁移,硬件平台的计算能力逐渐成为网络设备制造商考量的关键因素。在计算机世界实验室测试过的非模块化安全产品中,只要涉及病毒过滤、入侵防护、协议识别等应用层功能特性,设备的整机处理能力一般都不会超过2Gbps。在巨大的计算压力面前,目前主流多核/众核网络处理器强大的I/O没有了用武之地。

英特尔显然也看到了未来网络产品乃至信息化的发展趋势,一直从系统体系结构、处理器结构(内存控制器、多核/多线程、专用加速指令/引擎)、总线类型(QPI、PCIe)、网络控制器(8257x/8258x/8259x)等方面加以改进,大力提升x86平台的网络业务处理能力。同时,该公司还重新着手完成网络领域的产业布局,让x86平台更具竞争力。英特尔长期对Linux的发展提供全方位的支持,去年又收购了在网络领域很有影响力的系统解决方案提供商Wind River,力图为x86打造足够完善的软件配套环境。这就像选秀节目一样,英特尔在x86平台参与的新一届网络产品选型大战中充分发挥了业界巨擘的实力与影响力,堪称史上最强亲友团。

从尾随到超车

目前来看,这个亲友团表现得相当有作为。主打中低端网络产品市场的Atom平台凭借不错的性价比,抢得了相当规模的市场份额。以国内首家推出Atom平台安全产品的网御神州为例,该公司2010年基于该平台产品的出货量就达5000台左右。另一方面,在Wind River Network Acceleration Platform等软件系统的支持下,高端x86平台的网络处理性能提升迅猛,国内也有多个研发团队实现了10Mpps以上的转发速度,在指标上已开始赶超同级别的多核/众核网络处理器。

解决了产品和配套方面的问题,并不意味着就万事大吉了。实际上,x86在网络领域,仍然面临着一定程度的产业生态环境不健全的问题。相传,华为当年历经千辛万苦,完成了基于英特尔奔腾处理器平台的路由器开发工作时,却被告知所采用的处理器即将停产退市,气得领导们发誓永不再采用x86平台进行开发。这个故事也许只是极端个例,但任何一个网络厂商,都不能容忍连产品备件都无法提供的供应链事故。那么,面向通用领域的x86平台更新速度越来越快,产品生命周期也越来越短,如何才能满足嵌入式形态的网络产品的供货要求?英特尔的解决办法是,在现有产品的基础上,针对嵌入式应用推出拥有长生命周期(7年)、工作环境适应能力更强的特殊版本,给设备制造商吃个定心丸。没有了后顾之忧,x86平台在与专用处理器的竞争中才有足够的资本。

(6个打分, 平均:4.83 / 5)

感恩节之后的反弹

上周美国股市开始了感恩节之后的反弹。欧洲债务危机仍然继续,很可能短期内无法解决。美国经济数据持续增长,周二发布的消费者信心指数跃升到56,周五发布的失业率数据,降低到了8.6%。虽然每周新增申领失业金人数略有反弹,还是处于波动范围之内。各种迹象显示美国经济虽然增长力度还是不够,但是逐渐反弹了。强有力的增长,大量地创造就业机会,需要等待到一代人成长起来需要开始买房的时候。那样建筑业会重新发展起来,房价会重新升高,创造新一个房价泡沫。目前新增的家庭还没有足够创造这么多的建筑业就业机会,底层的劳动者要迅速地培训教育为高科技工作人员是不现实的。
现在的市场,大量优质股票价格低迷,处于富豪以低价掠夺更多资源的阶段。贫穷的普通工作者除了吃饭穿衣和供房,所剩无多。虽然市场上很多廉价的资产,但是一方面他们由于不理解,一方面剩余的财产不多,所以无法购买。而像巴菲特这样的亿万富豪,则趁机以低价大量吸收。同样的一个房屋,价格低了,但是产品的本质并无巨大变化。等到更多人有足够的钱来购买以满足基本生活需要,富豪会以比当前市场高得多的价格卖给民众,推高泡沫,然后再次挤掉泡沫,收进更多的社会财富。
欧洲这次的金融危机虽然是个坏事,但是处理得当也许变为好事。欧洲一体化的进程可能加速,金融领域联系更加紧密,政策方面也必须有相应地作出调整。整个欧元区的竞争力可能由于危机的化解使得竞争力进一步增强。欧元区债务庞大的国家必须要裁减福利,紧缩开支度日。大伙都能过好日子的时代已经过去了。新兴国家会把更多的钱用于自己的国内而不是放债给一些懒汉。
本周的美国市场预期会延续继续反弹的势头,欧债危机又会传来一些好消息。其实欧元区的问题一直是一个逐渐解决的过程,媒体推波助澜,一时夸大问题,一时又营造乐观氛围,市场起起落落。这个危机本身,需要欧洲更多的结构性变化,政策的改变,不会是一时印钱就能完成的问题。

(4个打分, 平均:2.50 / 5)