怀临评论–浅谈多核系统评估方法(Cavium vs. RMI)

Sina WeiboBaiduLinkedInQQGoogle+RedditEvernote分享




(7个打分, 平均:2.86 / 5)

雁过留声

“怀临评论–浅谈多核系统评估方法(Cavium vs. RMI)”有155个回复

  1. 开心果 于 2008-10-31 4:08 下午

    无语,从首席长期的言行来看,还是建议首席常回来看看吧,多接触接触国内的开发人员。在国外呆了一段时间在“高中同学”理论的浸淫下,让人很容易产生一种高高在上的错觉。而且老跟学生在一起就很容易好为人师,而国内的实情是,在学校被老师误导,在工作中重新学习。就个人素质而言,国内开发人员不像首席科学家想象的那么不堪。单挑华为的任何一个人这样的诳语,不是自我认识上面的偏差,一般人是很难说出口的。

  2. 陈怀临 于 2008-10-31 7:22 下午

    开心果,你为什么不能从我的录音中学点东西,而是又扯华为什么事情?ZTE是在用Cavium,华为是用RMI.我说错了吗?

  3. 潜龙 于 2008-10-31 9:50 下午

    不能说完全错,但不是很确切,世界上的事情不都像对联一样对仗工整:-)

  4. Eleven 于 2008-11-01 3:18 上午

    应该说,OCTEON和XLR都不是通常说的general-purpose multicore processor。而是陈sir多次提到的network service multicore processor.

    针对网络和安全方面的加速处理:
    1)OCTEON从两方面入手:一是扩展指令集和相应的运算单元,除基本的MIPS指令集外,CAVIUM还定义了用于加速密码运算等功能的指令及其运算单元。另一方面是在其I/O bus上挂上了coprocessor来加速TCP,compress/decomp等。
    2)RMI没用使用扩展指令集的方式,但它也在I/O Interconnect上挂上了10G security acceleration engine,特别适用于安全设备。

    OCTEON和XLR的出现降低了网络安全设备的门槛,给这些设备在国内的“山寨”化提供了平台。Huawei-symantec,Hillstone等好几个国内的也推出了基于XLR或OCTEON的的安全网关。
    从各自公布的参数上看,在性能上都次于Juniper的SRX。但进步也是有目共睹的。我们也不应该妄自菲薄。而Huawei-symantec的USG9300应该是性能和架构上最为接近的。
    以H-S的Secoway USG9300和Juniper的SRX-series对比,其架构极为类似,它们应该是高端架构的代表。在数据平面上,都用由I/O cards和service processing card组成;其中,接口卡都用NP(不知是哪家的,难道是IXP),业务卡用的都是XLR。

  5. 开心果 于 2008-11-01 3:32 上午

    受教受教,不过很抱歉,自负跟无畏我一样也学不来,你还是跟同学们讲吧。

  6. softmaster 于 2008-11-01 4:35 上午

    开心果,不要人身攻击。如果对BNN讲的内容有什么不同意见的话,就摆事实,讲道理的说出来。

  7. 陈怀临 于 2008-11-01 6:54 上午

    Eleven,你的评论相当专业。愚兄学习很多。希望您多来《弯曲评论》。

  8. 莲花木匠 于 2008-11-01 8:40 上午

    陈博太偏心了呵呵,先给RMI袒护一下,RMI实际上也有硬件加速引擎,内部同样有相关的L2/L3的解析以及CAM entry(这个是象征性的,数量很少)。(OCTEON了解的不多^_^)

    不过Eleven提到的RMI的10G security acceleration engine特别适用于安全设备,好像没那么乐观,要是用于安全设备的话倒是觉得OCTEON更合适。
    RMI号称是10G,其实充其量用在2.5G平台比较合适,IO上相对OCTEON有优势但也有硬伤:没有硬件保序,spi4相对比较弱。
    像这种评估确实是看各自的具体应用,各自的软件及平台,单纯的看芯片指标没什么用,更不用说厂家的demo数据(大部分都是吹嘘自己的)。

    像OCTEON和XLR的推出,正如陈博及Eleven说的:实际上还是定位在network service multicore processor,只是提供AMP的应用场景(部分core跑控制,部分跑转发),对于控制平面不是很复杂的线板来说移植量应该也不是很大(拿一个核跑控制的话)。

    在中国市场上最初RMI应该比Cavium进入的早,初期的市场应该是比Cavium大,但是Cavium有一手做的比RMI聪明:捆绑windriver推出,而RMI就很小气,自己搞搞自己的那个RMIOS和自己改装的linux。但尽管如此,Huawei方面在初期好像都热衷于RMI,包括H3C也是。不过走到现在,据说RMI忙着上市,路标也不清晰了,倒是Huawei方面又转头搞Cavium了。

    比较神奇的是半路Freescale又醒过来了,搞了个8572,虽然推的比较晚,但紧接着又搞出个QorIQ平台,从P1~P2~P4都有系列产品了,按Freescale这驾驶似乎要后发制人了。

  9. herace 于 2008-11-01 8:46 上午

    呵呵,知道了两个厂家背景;
    关于两个芯片选型,讲的有一定道理,就是讲的有点high level点儿,可操作性不高

    还有一点就是实践才真正了解芯片的性能,说再多也没用!

  10. 陈怀临 于 2008-11-01 9:16 上午

    我说了我不偏心的。周总是我的好朋友。RMI的人我也很熟悉。这么多年。。。:-)

    有一年,Cavium还是startup的时候,。。。圣诞节期间,其某款processor出了bug。。。。我们加班。。。其VP Engineering带人在现场陪我们。

    我当时想,这些(印度高中同学)人不错。能吃苦,一定能上市:-)

    从技术把握上,RMI对软件并行化的要求和把握更高一点。这对具有大量Legacy代码的系统的挑战比较大。如VRP:-)

    对RMI,我喜欢其FMN Ring的Interconnect设计,与Memory Bus的分离。很漂亮。但没有Packet Ordering Engine和Regex Engine是缺点。2个SPI4.2 10G也不错。
    对Cavium,POE,Regex等是亮点。对大型并行计算的能力保持怀疑。其Memory Bus Latency的缺点比较严重。

    总的而已,都不错。咱们神州大地现在都没有这个能力做这样的高端的Network Service Processor。

  11. Eleven 于 2008-11-01 11:16 下午

    班门弄斧,让首席见笑了。

    一款芯片性能怎样,是否满足需求,光看厂家的性能指标确实不是完全可靠的。最好是有第三方的测评报告,比如类似于EEMBC的性能报告。不知有没有关于OCTEON和XLR的测评,呵呵。

    话说回来,任何一款芯片都不是十全十美的,更何况复杂的Network Service Processor。不会出现致命的bug,或者有小的bug,但存在能不严重牺牲性能的workaround,就谢天谢地了。

    正如陈sir说的,一款高端NSP应该是产品功能、性能需求,市场定位,成本(如die size),功耗,工艺水平,项目的schecule,设计团队的能力和偏好等诸多因素下的trade-off。

    比如SUN的UltraSPARC T1,它有8 cores, 4 threads per core.但是整个处理器却只有一个shared FPU,而不是每个core上都有。如果用于Server上,它的浮点处理能力太低。但它的天才设计者们不可能连这点都考虑不到。事情的情况是,当时他们所设计出来的T1面积太大,foundry的工艺没法满足在保证yield的基础上做这么大面积的die。所以只好忍痛割爱砍掉了每个cor的FPU。而在设计下一代的T2时,工艺已不是问题,FPU也加上去了。

    同样的道理,相信OCTEON和XLR的设计者们也有很多的trade-off。他们的市场定位好像并不是100%重合,CAVIUM做的蛋糕貌似更大。

    比如OCTEON为什么没用使用multithreading呢?源于DEC/Alpha的CAVIUM设计团队在multithreading方面的实力肯定是没问题。在网上看到一个英文评论,说是他们一开始是准备设计multhreading的,后来放弃了。他们认为包处理任务是一个数据并行任务,在他们所设计的架构和memory hierarchy下,并不存在严重的’dead time’或者memory latency问题,需要用多线程来掩盖。他们的仿真也表明,在performance/watt方面,多线程设计并不会给他们的设计带来更多的有效性。也就是说,如果再使用多线程设计,性能可能只提高了一点点,但是功耗/面积/成本却增大很多。

    类似于OCTEON和XLR的高端NSP,国内目前确实没实力做出来。但应该还是有一些人想做。只是都是一些个体,没法build起来一个有实力的team,在业界也没有类似的公司有这样的项目让大家来take.我想只要能出现一家这样的公司,即使创业失败,能够培养起来一批人,还是有希望的。

  12. 中兴之象 于 2008-11-02 3:17 上午

    Cavium前段买了Star 900M$

  13. 陈怀临 于 2008-11-02 7:10 上午

    Eleven的评论相当对。我这几年一直在参与设计一个高端网络处理器。确实,许多漂亮的东西到最后因为Die和功耗的原因,不得不砍掉了。。。

  14. 陈怀临 于 2008-11-02 7:19 上午

    “或者memory latency问题,需要用多线程来掩盖。”

    同学们请注意,这是非常漂亮的一个对Hardware Multithreading技术的理解。同时可参考我的音频ILP vs TLP里说的:“当一个Load或Store在cache miss时,其他Hardware Thread可以切换进来利用计算逻辑。。。”

    再次谢谢Evelen。

    一起努力,一起加油,把你我的一些心得,经验分享给大家。

  15. 蛋蛋 于 2008-11-03 8:12 下午

    B大有空能不能讲讲各种体系结构x86,ia64,sparc,mips,Power等的
    特点,比较与前景等等..

  16. 陈怀临 于 2008-11-04 6:39 上午

    这里面我对Sparc不太熟悉,除了当年设计编译器的时候,借鉴过其register window的idea。对其他,再加上xscale,应该都是火线上拼杀,经验很多。确实希望能把知识,特别是经验共享给大家。

    我可能会在最近开一个open source的项目在sourcefage上,关于这方面的。

    这个星期准备录制一个如何为网络处理器设计编译器。不知读者们有无兴趣。我想把这方面的经验也与大家分享。设计编译器的机会很少,希望大家喜欢,并有所帮助如果你碰巧要涉及这方面的工作。

  17. 莲花木匠 于 2008-11-04 7:46 上午

    感谢陈博的分享

    对于我们新手总觉得找不到北,好多东西要都是独自一点一点摸索的话太漫长了。。。

    另外,陈博对路由器也是很有研究能否把你对LR(Logic Router)以及运营商对LR的理解给大家普及一下?

  18. softmaster 于 2008-11-04 7:51 上午

    期待BNN的新作。
    附带提一下,我们公司最近开发了一块网络处理器。其硬件的代码逻辑,微码的编译器和调试器都是工具自动生成的。使用的是Target Complier Technology公司的开发包。BNN对这样的技术有什么评价。

  19. 匿名 于 2008-11-04 8:14 上午

    代号是”自研NP”项目?哈哈

  20. softmaster 于 2008-11-04 8:35 上午

    我对这块片子的设计过程介入不深,而且很多技术是不对国内公开的。不过有两点体会与大家交流一下:
    1)如果EDA工具发展到这一步的话,开发一块高端NP的门槛是大大降低了。当然,前提是EDA工具不能太贵。
    2)片子设计的风险还是在系统设计阶段。除非你对要用这个片子设计的系统十分了解,设计缺陷基本上是不可避免的。如果在FPGA验证阶段发现还好,如果在ASIC流片阶段发现,那简直是要了命了。

  21. heshuangbo 于 2008-11-04 11:07 下午

    to 陈:
    “我可能会在最近开一个open source的项目在sourcefage上,关于这方面的。”

    到时一定要知会一下啊

  22. 陈怀临 于 2008-11-05 11:18 上午

    好的。我下星期就到sourceforge上去申请。目的就是把一些实战经验共享给年轻的学生或工程师。

  23. Eleven 于 2008-11-06 7:42 上午

    Processor Watch: Loongson-3

  24. eric 于 2008-11-08 1:47 上午

    陈博对TILERA的TILE64多核处理器有什么评论,现在中国和RMI等是竞争。

  25. Eleven 于 2008-11-08 9:02 下午

    说两句softmaster提到的使用EDA工具自动生成处理器的硬件RTL代码,compiler和debugger等。
    现在的产品需求各式各样,一个处理器不可能都能满足各种需求的。所以才会出现configurable processor和application specific instruction-set processor (ASIP)的设计方法。
    我一直看好这个方向。只要有成熟的EDA工具,嵌入式处理器肯定会朝多样化发展。面向具体应用,生成能较好的匹配该应用的指令集和和处理器结构,使之能满足性能等方面的需求。当然,更重要的是,能自动生成compiler等工具,否则软件开发就是恶魔。
    目前,做的最好的应该是Tensilica.
    在高端网络处理器方面,Cisco也早已用上了这个方法。设计QuantumFlow应该就有使用Tensilica的工具。比较有意思的是,Cisco既是Tensilica的投资者之一,也是其客户。

  26. 陈怀临 于 2008-11-08 9:21 下午

    ASIP是个非常重要的方向。国家一定要重视。
    编译器是个比较偏门的研究和工程方向。愚兄个人窃以为编译器自动生成比较难。

    我个人不太自信编译器:-)虽然设计过一个NP的编译器。但处理器微结构一旦复杂,如超级流水线结构的,编译器的难度是非常大。

  27. Eleven 于 2008-11-08 9:22 下午

    一直很关注Tilera公司。很大部分处理器一样,它也源于校园。它是MIT一个教授十几年研究的产业化。

    其TILE处理器已超越了一般意义的multi-core,用many-core应该跟合适。它与QuantumFlow有几分相似。

    TILE主要面向两个应用:networking和video。

  28. Eleven 于 2008-11-08 9:40 下午

    接触编译器很少,俺不知天高地厚。呵呵。

    是的。所以,现在的所谓自动生成都有很多限制的。指令和结构都是基于EDA厂家所提供的基本框架的限制下的。其状态应该是semi-auto或者什么初级阶段吧。

  29. 陈怀临 于 2008-11-08 9:46 下午

    其实这个自动生成,semi-auto是最高境界。剩下的都是手工调:-)。芯片的physical设计也是如此。全靠EAD的都是相对简单的部分。

  30. Eleven 于 2008-11-08 9:57 下午

    嗯。所谓“师傅领进门,修行靠个人。”这次的师傅是EDA工具。对于设计者而言,真正custom和manual的部分,才是art的体现。

  31. 蛋蛋 于 2008-11-18 9:17 下午

    B大啊,等着你的open source的项目呢。

  32. 长风 于 2008-11-27 7:59 上午

    博士,
    您对RMI有偏见的,RMI也有网络加速器,也有安全引擎,也有加解压引擎
    跟Cavium都是一一对应的
    更难得是RMI是多核多线程,应用在网络上,吞吐量很大。
    Cavium在国内现在基本没有什么市场

  33. 陈怀临 于 2008-11-28 10:41 上午

    我没有拿RMI的赞助费,不会有偏见的。Cavium的周总除了与他的弟兄们夸我,也没给我钱:-)

    感觉Cavium现在实力强一点,比较通过上市公司筹建了一批银子。。。。。。

  34. 校友 于 2008-12-01 7:59 下午

    陈博,很高兴能听到您的精彩评论。我马上也要做一个类似的评估,前期搜集研究了一些资料,对这个话题有些不同见解。如您方便,请赐邮件,希望能和您详细沟通一下。谢谢。

  35. 陈怀临 于 2008-12-01 10:19 下午

    校友同学,我的通信地址为:huailin@tektalk.cn
    谢谢。

  36. alex 于 2008-12-03 8:45 上午

    中国首台万亿次计算机亮相:花费不足80万

    花费不足80万元,占地只有一台家用冰箱,你能想象这是一台万亿次计算机吗?近日,我国首台采用国产高性能通用处理器芯片“龙芯2F”的万亿次高性能计算机“KD-50-I”在中国科技大学研制成功,并于日前通过了以王守觉院士为主任的专家委员会的鉴定。它的理论运算峰值为10080亿次/秒,这是我国高性能计算机国产化的一次重要突破。

    处理器芯片自主研发

    “我们给这台高性能计算机命名为”KD-50-I”,其中”KD”是科大的简称,”50″意味着明年中科大的50周年校庆,”I”就是第一台的意思,希望在不久的将来,我们能继续开发出基于龙芯3号多核处理器的高性能计算机系统”KD-50-Ⅱ”。”项目负责人陈国良院士介绍说。

    图:龙芯二号超级计算机研制成功
    在已公开报道的运算次数达万亿次级的国内超级计算机中,中央处理芯片主要来自IBM、Intel或AMD等国外公司,基于我国自主研发的处理器芯片的万亿次计算机系统的研制成功还是首次。

    在教育部“985工程”建设项目的支持下,自2007年5月以来,中国科大计算机科学技术系与中科院计算技术研究所密切合作,采用代表国内当前高性能通用处理器设计最高水平的64位“龙芯2F”芯片,研制国产万亿次高性能计算机。以陈国良院士为项目负责人的研制队伍,经过几个月的紧张工作和技术攻关,终于在近日研制成功。
    运算万亿次耗能不到六千瓦

    据了解,“KD-50-I”万亿次计算机采用单一机柜,集成了330余颗“龙芯2F”处理器,理论峰值计算能力达到1万亿次,整机系统结构先进,采用了高密度节点设计技术。硬件系统采用了我国自主设计的龙芯2F处理器、华为自主研发的千兆以太网交换机等。

    “KD-50-I”具有“三低一高”的特点,首先是低成本,每(运算)万亿次,75万元人民币就可以买到;低功耗,每(运算)万亿次,耗能六千瓦之内就可以了;还有低占地面积,我们336个CPU把它安装在一个机箱里面,目前它的体积大小只相当于一个冰箱;那么这个“冰箱”相当于我们这个中心机房五套进口的国外的整个计算机的计算量。

    “此外还特别适合于高性能计算教学和科研方面的应用以及创新型人才培养”。

    陈国良院士深情地表示:“在我小的时候,用的火柴叫”洋火”,火柴盒子上都写着”安全火柴,提倡国货”,这句话给我留下了深刻的印象。那时候,我们的民族工业还十分脆弱,但民族感始终那么强烈。如今,”KD-50-I”高性能计算机是完全由我国自主研制的,确立了国产高性能通用处理器在高端并行机应用中的核心地位,为我国未来研制国产千万亿次计算机提供了示范作用,对推动我国民族高性能计算机事业的发展和国家安全都具有重要的战略意义。

    吓人哦。。

  37. Fake-Einstein 于 2008-12-04 7:16 上午

    陈老师,从您提供的信息来看,您掌握的资料都太旧了。其实从来都没有ZTE用Cavium,Huawei用RMI这回事。从ZTE和Huawei本身的利益来看,仅选用一个供货商也是有风险的,更何况现在以及过去的情况也不是如您说的那么简单。总的来讲,现在在Huawei还是用Cavium的多一些;ZTE则是两家都有用,低端产品中主要是Cavium,高端产品用RMI的多些。据说国际市场上Cavium的表现要好些,而Raza那个老头其实早已离开了RMI,且RMI的高层基本都已经换了一茬,现在金融危机一来,我对这个公司的前景还是有些担忧的。
    客观的讲,陈老师对多核处理器的评论说的很有道理。对多核处理器,我更关心的是他能够提供给开发者一个什么样的平台,在这个平台下设计的应用的复杂度,可扩展性,可维护性,可移植性等。因为对于一个系统工程来讲,其实性能往往反倒是一个相对次要的因素。因为说白了这两种处理器性能都不差,有的好些有的差些,但都是很优秀的了。而做设备对开发周期其实是很敏感的,不管性能怎样,到时间了设备出不来那才是最要命的。而且性能和复杂度是成反比的,在某种情况下性能好不能说明在所有情况下性能好,性能都是相对的,并不好评说谁比谁绝对好。所以对于设备制造商来讲,一是要向陈老师说的那样,关注自身应用的具体需要,实际的考察两种处理器的能力;再有就是要考虑使用和开发的难度。关于这两方面我对RMI这个东西就很有些感触,环状总线,多线程看起来是很炫,但是实际用起来会怎样呢?千万千万别忘了我们是要做工程,不是在搞科学研究,我从来都不相信什么所谓的多少万亿次计算的什么超级计算机,噱头是不能当干粮吃的,这都是有血的教训啊!同理Tilera那个东西我就更觉得不靠谱,谁敢用啊,扯的有点远了。我参与过很多基于RMI的系统设计,和基于单线程的平台相比,复杂太多了!最要命的还不是多线程,那个环状总线上N多的Station,Bucket简直能把人绕到死,简单的说想从SPI4接口收发个报文你都得设计一整套的总线的Station,Bucket索引机制,而且还要和其他所有的索引机制共存,错一点所有人都别想转起来,基本功能都谈不上了。其实很少有一种处理器在设计上层应用时还要你考虑总线这么基本的单元,现在想想RMI真是一个个例。而且这个问题往往系统设计初期并不明显,而随着系统的日益庞大和复杂就越来越突出,我们做设备不是做玩具啊,杂七杂八的需求一加,倒霉就开始了,到最后基本没法收拾。更别提软件从8个Station的平台迁移到16个Station上,想想一个那么复杂的系统,能做出来已经是阿弥陀佛了,再把可移植性考虑进去,非要出人命不可了。还有后面处理器的换代呢,他不能总是8个核吧,他接口总要变化吧,总线总不能天天变吧,不能提,一想到这些我就头疼。后来我也想明白了,其实讲基本概念大家都好理解,关键是在用你这个工具实现同样功能时谁花费的工作量大,而基本工具的复杂和应用不友好会使得基于其上的应用复杂度成几何级数的方式增长。我现在绝对相信简单的就是最美的,不是有句话么,“简单的不一定是最好的,但一定不是最差的”,这句话说的太有道理了!选择处理器,我一定首先要看的就是应用复杂度,这个是雷打不动的,其次才是性能,功耗,成本等因素,很多人就是喜欢倒着看,有时碰运气也能选对,但是有时候就没那么幸运了。

  38. 陈怀临 于 2008-12-04 7:31 上午

    假爱因斯坦,非常谢谢你的评论。一看你就是真枪实弹的摸过RMI的。是的对station和bucket的处理要非常小心。非常subtle。RMI能把握好做一个系统确实不容易。希望有机会与学弟您多交流。感觉你对华为和ZTE都很熟悉嘛。。。对RMI的内幕也知道许多。我还真不知道George已经开溜了。。。。。。唉,还有好几个朋友在RMI呢。希望RMI也能上市。。。。。。

    有时想想很可怕。如果Cisco买断Cavium;哪家公司买断RMI。Cisco估计也会买断EZChip。。。。你说这如何是好???

  39. Fake-Einstein 于 2008-12-04 7:47 上午

    陈老师过奖了,很多东西我也只是道听途说。其实这两家公司的技术创新都非常有特点,都很值得研究,但对于应用者来讲,感受会不太一样。
    Cisco确实非常强大,他要不要干一件什么事情还真不好说,要看值不值得了。RMI不知什么时候能够上市,Cavium上市了,EZChip也是上市公司。收购成本不太一样,但对这几家公司任意一家的收购都会在通信业引起波动,毕竟在市场上大家都要看大象的眼色行事,他哪天怒了,大家都没好果子吃。

  40. 黄岩 于 2008-12-16 5:59 上午

    非常精彩,特别是其中这样一些观点:(1)要根据自己的应用来评估芯片的性能;(2)不要只看重性能,还要关注技术支持的可获得性;(3)做网络设备,除了比较时钟之外,还要比较总线带宽、外围的加速引擎等;(4)要根据自己的能力选择芯片,要关注研发投入。

    另外我觉得,选芯片跟选股票查不多,股评家的方法我们可以学习,但是股评家的结论不能轻易相信。比如陈先生说的:小公司选cavium、大公司选RMI,这些结论,应该都不是绝对的。股市有风险,入市需谨慎:)

  41. 陈怀临 于 2008-12-17 8:01 下午

    谢谢你的支持。让你,我,潜龙,等各位志同道合者共同建立一个优秀的科技,潮流,人物的媒体。We can do it. 我们有责任把自己的一些经验共享出去,为了心中的一些理想。

  42. 过路者windfinder 于 2008-12-18 5:24 上午

    我是第一次听陈先生的讲座,感觉不好。其实陈先生可能对RMI和Cavium的处理器并不了解或不熟悉,所以没有实质的东西可讲,内容和标题不搭调。根据自己的需要选择处理器这是任何实际产品所需要遵循的基本原则。

  43. test 于 2009-01-15 3:38 上午

    同感,对这两款处理器的确不了解。这两个产品的一些信息可以从的其公司网站或是一些网络公司的网站上找到,在此基础上如果楼主精通CPU的内核原理,应能预测到其各自的优劣势。退一步,只要和RMI和Cavium的老总聊几句,也就能知道各自的优劣了。补充一下,其实RMI初始开发相对容易,Cavium的初始开发相对难。这也是国内部分公司选择RMI的理由之一。对一些公司背景内容的介绍,根据我的粗浅了解,应是不错的。

  44. njxhf 于 2009-03-10 4:12 上午

    找到前辈了,可惜怎么只能听到前面2分钟呀。
    我们刚开发完成CAV5860的硬件平台,

  45. njxhf 于 2009-03-10 4:21 上午

    不知这次金融危机对他们有没有影响?

  46. 帅云霓 于 2009-05-08 6:28 上午

    关于RMI的处理器,不得不说
    RMI处理器内建的Network Accelerator,FMN,其功能很强悍,但也很鸡肋。
    Network Accelerator可以由硬件分析提取出数据报首部的一些关键字段,放置在报文Buffer的prepad空间,并且对其作硬件HASH运算并依据一定的规则Load Balance到各个Thread上,已经接近NP的功能,但编程比NP灵活得多。这看起来很美——已经有厂商用RMI平台设计出Throughput达20Gbps/30Mpps的安全产品。但是,有一个深远影响的方面,就是:这些代码是硬件强相关的,非POSIX标准的,易言之,就是不可移植的!实际上,从长远来说,使用了RMI内置的Network Accelerator,就是服用了兴奋剂,虽然可以提高performance,但其负面影响是难以估量的。
    一点个人意见,如果有不对还请各位大侠海涵!

  47. 老韩 于 2009-05-10 3:07 上午

    呼唤陈老师给做一个RMI XLP的技术分析,谢谢

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

    小帅,你的论点说对,也不对。POSIX是一个操作系统的规约,要能管到这些地步,世界就乱了。

  49. 陈怀临 于 2009-05-10 8:25 下午

    对于多核CPU和相应的多核系统。从大范围而言,Programming Language, OS,Middleware都不ready走出实验室。然而,工业界的demand使得必须实用化了,而学术界又基本上没有能力和不知道工业界大规模应用的需求。从而导致工业界基本上是摸着石头过河。

    归根到底,并行计算很复杂。

  50. 帅云霓 于 2009-05-10 11:46 下午

    一点儿个人看法,当系统演进到多核时代以后,操作系统和处理器越来越成为一个整体。以RMIOS为例,虽然也是基于改造的Linux,但里面有大量的处理器相关的代码。RMI的XLR多核协作需要用内建的FMN,而FMN又占用了MIPS的CP2,因此相关核间操作、网卡收发操作里调用的函数都是特别为RMI实现的。
    也许,将来的系统设计,更多地需要用’面向对象’的方法,不要将软件和硬件分得那么清楚,而是针对需求来设计。如设计一个Firewall时,从一条数据流(Stream)的处理次序来考虑,也许会看得更清楚些。

  51. 陈怀临 于 2009-05-11 9:30 下午

    我现在对系统的理解是:ASS:–)Application Specific System。换言之,所谓系统设计就是为了你的问题,解决问题,寻找你自己工程问题(其实是市场问题)的近似解。

  52. FLP 于 2009-08-01 6:54 下午

    怎么突然看不了了

  53. 陈怀临 于 2009-08-01 7:51 下午

    我刚刚试了一下,我的机器还可以听。

  54. zz 于 2009-08-18 8:31 下午

    没声音了

  55. Panabit 于 2009-08-20 2:37 上午

    “我现在对系统的理解是:ASS:–)Application Specific System。换言之,所谓系统设计就是为了你的问题,解决问题,寻找你自己工程问题(其实是市场问题)的近似解。”,用术语DSSA(Domain Specific System Architecture)描述更合适一些,呵呵。Panabit运行的Panaos就是一个DSSA的典型事例。

  56. qqdavid 于 2009-09-22 1:15 上午

    不好意思,把这个老话题又翻了出来。最近公司在调研TILEA的TILE64,也与相关技术人员做了沟通,听他们说该器件64core,采用二维mess总线,性能非常了得。单颗随便支持10G小包深度检测。就是很依赖该公司的开发套件。这里想请教各位,目前该器件性能是否像宣传的那样?采用该器件是否有一种被绑架的感觉?也就是说是否弱化了公司的技术优势?谢谢!

  57. david 于 2009-10-15 7:19 下午

    恰好刚完成一个基于rmi的项目,感觉fmn没有大家说的那么复杂啊,配置管理起来很方便,一个config文件就ok了。

  58. 陈怀临 于 2009-10-15 8:19 下午

    这说明你已经是狠人了!!!:-)你的这个感觉类似于:看了BGP的RFC和某个开源实现之后,觉得BGP很简单呀。。。

    现实情况是,业界敢说懂BGP的人我目前听说过,但只见过一个人。

    为什么,corner case太多。。。

    工程问题怕的是:边角料的问题。99%的时间要去fix那1%的问题。。。

    例如,BGP的Peer崩溃,你的系统能否搞定?Forwarding能否线速。。。。

  59. 李克 于 2009-10-15 9:35 下午

    To qqdavid:市场销售哪有不撒谎的
    BGP是看起来简单,实际比IGP还烦,BORDER呀,border都接触什么人,好人懒人一大堆,所以实际情况很复杂

  60. 帅云霓 于 2009-10-15 9:40 下午

    [恰好刚完成一个基于rmi的项目,感觉fmn没有大家说的那么复杂啊,配置管理起来很方便,一个config文件就ok了。]
    等你往系统上面加东西的时候,比如打开里面的SAE,或者启用一个SPI的时候,算credit和bucket里面那些龌龊事就能烦死你。

  61. 高飞 于 2009-10-15 10:58 下午

    学术界说懂BGP的人我倒是见过一个。

  62. michael 于 2009-10-16 1:44 上午

    懂得bgp又能写成软件做好的人,除了tony lee还有谁。

  63. aaaa 于 2009-10-16 4:24 上午

    多的去了, 估计楼上这位只是个application engineer罢了..

  64. 杰克 于 2009-10-16 5:09 上午

    思科有几个DSE对网络协议的应用非常精通,但是理解,应用,实现实在是不同领域,思科的fellow们,像fred,dino,tony li都算是高手了。

  65. bbc 于 2009-11-06 8:09 上午

    fred很好玩的, 据说以前还是个木匠

  66. 路过 于 2009-11-12 8:57 下午

    Cavium花5000万美元收购Linux嵌入式厂家MontaVista

  67. jessica 于 2009-11-29 12:20 上午

    楼主有没有文字版啊?

  68. 向各位大虾求助!!! 于 2009-11-29 8:13 下午

    我们学校的项目要求我们必须要买一台
    Cavium 58xx的评估板,要求包含所有必须软件(TCP/IP协议栈、SDK等),但是我在国内就查到2家代理,而且要价非常高,总共算下来要30-40W左右。

    不知道大家知道其他的购买渠道没?

    事情紧急,小弟先拜谢了!!!

  69. z3326 于 2009-11-29 8:22 下午

    找H或Z的哥们去弄一套,应该还是Free的.代理基本决定不了

  70. 向各位大虾求助!!! 于 2009-11-29 8:49 下午

    谢谢69的大哥。

    刚才跟huawei的销售谈过了,对方说不能单卖这种开发板和相关的软件,很客气的拒绝了我。

    我想可能还是因为小弟没有熟人的原因。

    各位有相关信息的高手,请务必救小弟一命啊~~~

  71. klab 于 2009-11-29 11:09 下午

    可以找一些专门做防火墙、加速卡的方案厂商,给我你的邮箱,我可以发两个厂商的资料给你看看

  72. 向各位大虾求助!!! 于 2009-11-29 11:18 下午

    好的,谢谢楼上大哥。

    我的邮箱:

    fdetert@126.com

  73. klab 于 2009-11-29 11:44 下午

    已发邮件

  74. 理客 于 2009-11-30 4:16 上午

    你要的这种东西,这种价格,我看是没解的。建议直接和芯片供应商联系,因为他们本身即有demo板和相关软件,但大厂商本身关注的首先不只钱的问题,而是能够合作双赢的问题,比如你有一个863项目,投资千万,要找商业公司合作,这种情况下是比较容易或者你要的板子和软件,没有类似的这种情况,基本上没人会为了三、四十万就卖。你说的代理商,卖的估计也就是这种demo板,个人认为,严格意义上,代理商的行为是非法的,demo板可以免费给大客户使用,但是不会允许你转售

  75. 向各位大虾求助!!! 于 2009-11-30 5:19 上午

    To 73:我已经和他们联系过了,估计希望不大;不过还是非常感谢您的帮助!

    另外,LS说得有道理,感谢帮助。不过我们这只是一个小项目,我又只是一个穷研究生,手中没有可以和人家bargain的筹码,老师给的预算也非常有限,现在我也只能尽我所能想办法了。

    如果有愿意伸手相助的大虾,请直接留言或发到我的邮箱:

    fdetert@126.com

    万分感谢!

  76. 理客 于 2009-11-30 5:48 上午

    有志青年,good luck。
    一个可选的方法是去那些有这个资源的公司做兼职打工,获得免费使用

  77. 向各位大虾求助!!! 于 2009-11-30 7:17 上午

    哎,如果时间允许的话,LS说的倒是一个好方法。不过。。。

    要求放低点好了:各位高手们,谁能提供“可以运行在Cavium OCTEON系列多核平台上的TCP/IP协议栈”的,请联系我~~~
    fdetert@126.com

    价格可以商量~~~~~当然,不能比Cavium卖的还贵~~~

  78. 陈怀临 于 2009-11-30 7:12 下午

    能奔一下是哪个学校吗?不错嘛,研究生就开始摸Cavium的开发板了。

  79. 向各位大虾求助!!! 于 2009-11-30 7:28 下午

    首席太抬举了

    学校在首席弄的简介里面倒是位居前三

    可本人只是个门外汉而已,哈哈

  80. 陈怀临 于 2009-11-30 10:15 下午

    貌似清华Jun Li旗下的网络安全实验室?瞎猜一哈。即使对了也别当真:)

  81. IBM-LSI 于 2009-12-01 3:45 上午

    IBM新推出的PPC476内核有人有研究吗?LSI基于476做PPC的多核芯片,号称架构采用virtual pipeline,这有个什么优势吗?

  82. 呵呵 于 2009-12-01 7:22 上午

    首席猜错了哈

    身份不重要,呵呵

  83. 陈怀临 于 2009-12-01 9:44 上午

    Heeeee,没关系。我想你也不至于水平那么差,在清华混,那多丢份呀:-)

  84. 恩恩? 于 2009-12-08 5:11 下午

    清华怎么会丢人呢~

  85. lionfore 于 2009-12-22 1:16 上午

    请问各位大侠,XLR中的Peripheral I/O Bus和Octeon中的Boot Bus是不是相当的?

  86. 帅云霓 于 2009-12-22 4:10 上午

    差不多。

  87. lionfore 于 2009-12-23 2:19 上午

    多谢帅兄!再问一下,这两种Bus是不是与local bus也是类似的?谢谢!

  88. 帅云霓 于 2009-12-24 5:32 下午

    LocalBus这个概念的内涵和外延都不是很明确,我想您指的Local Bus应该是有Address/Data/WE/RE/CE构成的并行总线。这种总线又有两种制式,8086制式(WE/RE/CE/ALE)和6800制式(WR/CE/ALE)。它们的区别在于读使能和写使能是共用一条线还是两条线。实际上这两种制式也是可以使用CPLD逻辑相互转换的。
    您说的XLR和Octeon的这两种Bus的确可以属于LocalBus,具体可以看Datasheet和编程手册了。总之,将Nor-Flash、SRAM乃至并行A/D采样芯片之类的并行总线器件接入这个总线是完全可行的。

  89. 陈怀临 于 2009-12-25 7:29 上午

    小帅说的对。Local Bus是一个泛泛的词,是一个概念。

  90. 帅云霓 于 2009-12-26 2:24 上午

    首席过奖了。我只是有幸接触到过一个跟XLR那个Local Bus有关的难解的Bug,才对此有所片面的了解的。当然,我倒觉得储备一些硬件知识,对做软件,特别是infrastructure的东西,有非常大的用处。

  91. lionfore 于 2009-12-28 4:46 上午

    多谢帅兄和陈兄!两位的深刻讲解令小弟受益匪浅!小弟最底层就到CPU指令集、汇编这个层面,没有做过硬件,所以以后有机会多向两位请教!XLR和Octeon我都接触过,找时间写一些心得与大家share。

  92. boblee2000 于 2010-05-02 8:05 上午

    呵呵总算找到组织了,我觉得我应该算是接触多核比较早的了,我从IXP1200,IXP2400开始,然后是RMI的XLR532,到现在的Cavium的5650全都用完了,后面两款多mips核的复杂度和IXP的比起来,哪差的是相当的远啊,用完IXP2400以后,我用XLR532的时候基本都要流泪了,终于回到C的怀抱的,不用写微码了。那时候觉得532简直是太强了,太好用了,可惜啊RMI被netlogic收购了;发表下个人意见,我觉的没有很好的软件支持是多核的硬伤,RMI和Cavium都有自己的包处理专用库,就是那个什么RMIOS和SE,虽然这些东西能够将多核的性能发挥到最大,但是可移植性还是太差了,而且目前为止的大多数应用都是基于固定的操作系统的,但是从Cavium收购montvistr可以看出,Cavium已经意识到这个问题;不知道RMI有相应的办法没有,不过话又说回来,我倒是挺支持TILERA的,我相信TILERA肯定是后起之秀

  93. 陈怀临 于 2010-05-02 1:09 下午

    Tilera目前的问题也是操作系统方面。。。

  94. stingw 于 2010-05-04 9:24 上午

    没有摸过tilera,据他们称直接支持linux,有mmu,带硬件页切换,还会有什么问题呢?请教首席了。

    rmi最新的832处理器中加速器基本已经全了,包括之前没有的包加速,以及最让人诟病的linux不支持硬件页切换问题,但是他们ring总线的架构总让人觉得后续升级core没什么发展余地;4线程共用alu也是更多用在IO复杂的应用上,不然没有太多的性能优势;
    cavium之前在国内市场更多用在低端市场,他的68x据说还不错,没有用过就不发表意见了;

    至于mips多核的复杂程度,在732上也是见识过了,不只是相互互斥保护的问题,做28线程负载均衡简直是恶梦,单线程计算能力的不足、memory访问冲突,都会直接导致多线程无法并行起来达到性能最大化,最终还是靠分解应用来解决了问题。我觉得这不是操作系统问题,无论什么系统,都无法解决处理器固有特性的BSP配套问题。比如92楼提到的软件技术问题,大公司实际上并不关注,而更关注的是处理器更多核的演进,已经完成的部分能否直接重用。

    但是归根结底,多核处理器进大公司,关键还是器件质量问题,tilera架构再好,就那么七八十人的现状,就不可能进入大公司的主力产品中,而rmi的质量问题最近也是一直困扰他们的最大问题,还真不是什么架构或者技术问题。

    ps:比如说2400最垃圾的不是他的微码复杂度,而是他们的cache/ustore问题,一旦量大了基本用它的人必死。

  95. 打酱油的 于 2010-05-04 6:27 下午

    受教了!产品出来是给人用的,每个多核芯片都表达了它的设计者对网络应用的理解和芯片的定位。如同当年的IXP1200一样,饱受诟病,但不妨碍它广泛的应用,有线、无线都有它的身影。没有绝对好或坏的芯片,只有好或坏的芯片选型。

  96. hover 于 2010-05-06 6:07 上午

    IXP,Cavium和RMI的多核都搞过。对于多核个人有点肤浅的认识,感觉Cavium和RMI确切的说更像NSP,个人还是更看好Cavium一点。总体上感觉在高端的XLR732和CAV的5860比起来,接口的丰富性732是要优于5860的.不过XLR732没有流保序功能,而且比较起来Cavium的软件开发模式比较简单,SE可以裸奔也可以在LINUX下跑,现在又收购了montavista,在软件方面应该说更完备了。而且Cavium的芯片低中高配置均有,尤其是低端芯片的,我接触到不少小公司都在用,而比较起来RMI的中端芯片的软件开发难度则大了不少(RMI自己的FAE也有这种观点)。

  97. kevin 于 2010-05-06 4:41 下午

    关于tilera,我最好奇的是它怎么搞定linux下的mmu和cache的。100个core一起tlb miss+cache coherency。。。。。。。。

  98. system 于 2010-05-06 5:29 下午

    TILERA基于mesh架构manycore的cache coherency的确是有些magic的。TLB Miss和普通mips处理器没什么大差别。其实TILERA最大的强项在软件方面。

  99. Multicore 于 2010-05-06 6:31 下午

    TILERA 每个Core都有自己的MMU和Cache,数据通过片上网络来传输和其实就是计算机集群缩小到了芯片上,貌似不存在不同Core之间的Cache的Coherency的考虑。不同Core之间采用MPI原语进行数据交互,在鄙人看TILERA的时候,貌似还没有很好的系统开发支持,需要程序员自己制定并行算法策略然后实现。

  100. hover 于 2010-05-06 6:34 下午

    那TILERA像CCNUMA一样了

  101. viaduct 于 2010-05-07 5:43 上午

    华为有产品线是用Cavium的

  102. 过客 于 2010-05-07 6:23 上午

    To 99 multicore
    软件是不需要考虑cache coherency的,那个tile中的switch网络就负责了各个core之间的cache同步问题。
    诚如98所说,软件是tilera的强项

  103. mutlithreaded 于 2010-05-08 3:12 上午

    应该把眼光放大一点,考虑一下X86和PPC的通用多核。
    这些基于MIPS的多核会逐步地被通用多核所取代。

    Tilera应该是用于DSP的多核,用于网络有点牵强附会了。Tilera如果用MPI通讯如何支持Cache Coherence?

  104. John 于 2010-05-08 7:16 上午

    通用多核的通用是什么意思?

  105. mutlithreaded 于 2010-05-08 2:59 下午

    General-purpose, 像最新的intel的8核,AMD的12核。。。

    当L3的cache高达24/32MBytes时,不知这些MIPS多核如何和X86/PPC的多核比性能?

  106. anch 于 2010-05-08 5:32 下午

    PPC也能被归入general-purpose?

  107. system 于 2010-05-08 7:37 下午

    Intel大佬也推出了一款49 IA32的处理器,起了个名字叫做”Single-chip Cloud Computer”,
    http://techresearch.intel.com/articles/Tera-Scale/1826.htm , 个人对general-purpose的理解是“ 大部分工作是依赖于软件和通用OS,而不是硬件加速或微码来完成的处理器, MIPS, X86, ARM都是通用处理器core,但虽然集成了通用的core,但主要工作却是靠硬件或者微码完成,这个SOC就不能叫通用CPU。所以PPC里面的7447, 750(APPLE以前的MAC就用这个)是通用的,但是8260之类叫做通讯处理器,主要价值是CPM。

  108. system 于 2010-05-08 7:43 下午

    mutlithreaded兄, 如果TILERA不能用于网络应用,那TILERA集成那么多网口干啥呢, 答案当然是肯定的呀。
    TILE-Gx100 TILE-Gx64 TILE-Gx36 TILE-Gx16
    Number of Cores 100 64 36 16
    Core Frequency 1.25, 1.5GHz 1.25, 1.5GHz 1.25, 1.5GHz 1, 1.25GHz
    Network Interface 2x 40G Interlaken
    8 XAUI, 32 SGMII 2x 40G Interlaken
    6 XAUI, 24 SGMII –
    4 XAUI, 16 SGMII –
    1 XAUI, 12 SGMII
    PCIe Two 8-lane
    One 4-lane Two 8-lane
    One 4-lane One 8-lane
    Two 4-lane —
    Three 4-lane
    DDR3 Controllers 4 4 2 2
    DDR3 Frequency 2133 MHz 1600 MHz 1600 MHz 1333 MHz
    Package 45 x 45mm BGA 45 x 45mm BGA 35 x 35mm BGA 35 x 35mm BGA

    http://www.tilera.com/products/TILE-Gx.php

  109. anch 于 2010-05-09 2:04 上午

    PPC多核和MIPS多核是一回事的,跟X86是很不一样的。

  110. mutlithreaded 于 2010-05-09 4:27 上午

    TILERA不是不能用于网络应用,而是他的基因不适合于网络应用。 如果你读过TILERA出道的论文可能会仍同我的观点。

    再有一点,基于SUIF COMPILER的系统不知稳定性如何?TILERA还用SUIF吗?

  111. mutlithreaded 于 2010-05-09 5:37 上午

    PPC的多核是指Power7的8核处理器。

  112. system 于 2010-05-10 4:41 上午

    Mutithreaded兄,看来对RAW还是比较了解的,不过还是要以发展的眼光看事物,TILERA的确是可以做网络的,RMI,CAVIUM能做的,TILERA也都能做,而且性能也不赖,如果有兴趣,找个板子让mutithreaded兄试试。 TIELRA现在用SIG或者GNU的compiler

  113. boblee2000 于 2010-05-10 6:42 上午

    我解释一下tilera的cache coherency,tilera是通过一个内存的home tile来实现cache coherency的,说白了就是用一个核专门同步cache和内存,这个核负责管理所有或者一部分核的cache和内存的同步问题。再说一下,tilera内部集成了XAUI万兆和GE接口,虽然他们有RMI和Cavium的类似的网络加速器件,但是由于他本身的核的数目众多,以及高速datepalne,完全可以拿出几个核来利用软件实现RMI和Cavium中的FMN和PKO等类似的加速功能,个人非常看好tilera!!呵呵

  114. 老刘 于 2010-05-10 6:42 下午

    还没看见有那个大客户在用Tilera.
    知道的晒一晒。

  115. stingw 于 2010-05-10 8:41 下午

    技术好只是一个方面,如果真要进大公司,还有很多事情要做。

    不过,分析tilera的2d mesh架构,某种意义上来说,tilera是真正解决核数增长问题的供应商;RMI的ring,cavium、ppc等的fabirc,一旦核数超过32个,感觉架构就必须变化;路标上也没有看到这些供应商有什么想法的。

    倒是x86年底的crastal forest架构变成了ring,加上cave creek的加速器,在通信行业竞争力提升的不是一点半点。 不过一直不太明天,加速器都在南桥里,所有的包处理、DPI、加密、算法都需要访问内存,势必CPU到桥片是一个瓶颈,虽然目前理论上带宽是足够的,但是真的没有其他问题么?

  116. 老刘 于 2010-05-10 9:51 下午

    我相信工业界正在储备/预研many-core的互联体系。

    问题的核心还是
    是否现在我们真的需要64核、甚至100个核来处理网络数据流呢?

    10G多核处理器是现在的主流需求,40G的需求正在井喷,100G还有一段路要走。

    目前主流的多核处理器基本上处于10G~20G的能力。Netlogic的XLP832和IBM的WSP号称是40G的多核,算是踩上了下一个点。

    但40G、100G目前是NP的天下,或者说的ASIC的天下。剩下的到底有多少份额值得去做呢?

  117. 老刘 于 2010-05-10 10:13 下午

    请我们的专家客客(理客)来讲一讲目前的主流带宽需求

    1)接入

    2)汇聚

    3)核心

    4)传输系统

  118. 理客 于 2010-05-10 10:42 下午

    回老刘:
    首先,毫不谦虚的说,我离专家的距离还很远,这里作为普通的网络工程师发表一点肤浅的comments,仅供大家参考
    总体上,还是摩尔定律在发挥作用
    1、接入,主要是视频和高速internet接入,后面在Google等引领下,肯定有更多高带宽需求的应用出来,这是后续带宽需求最大的地方,手段主要是VDSL+FIBER(PON),带宽需求开始是10M,后面是20M… 10M普及的时间很难说,看视频和高速internet中的application普及情况而定,技术上没有门槛
    2、汇聚:因为接入带宽的提升是略早于汇聚的,这里汇聚就是城域网,所以目前许多运营商在扩容城域网,10G是基本的,因为基于历史的经验,所以对于大T,40G/100G已经就在眼前。在ME的接入部分,用GE的还很多,但考虑到1里面的因素,10G的普及应该不会太慢,这里移动宽带(MBB)随着HSDPA+和后续LTE的部署快速发展,刺激了mobile backhaul和接入到汇聚部分网络的带宽提升
    3、核心网带宽随着上面的需求自然会起来,但这部分相对比较容易,并且提升的速率不会那么快,毕竟POP是在CORE外面的,所以ME和CORE可能都会在100G的level
    4、传输:ATM/SDH在10G/40G/100G的时代,已经从过去的宽带技术变成了现在的窄带技术,所以会被先后淘汰,而PON/FIBER/CWDM/OTN会成为主流传输技术,目前正在普及中,只要internet application对带宽的需求再猛烈一些,传输和承载网络目前暂时没有大的技术门槛,而对应的芯片技术,目前正在成熟中。网络和application是既独立又相辅相成互相促进的一个整体,从这点看,CISCO要NG CRS-1卷入云计算等领域,也是一个很好的idea
    总结一下:网络正在ready,让internet application的炮火来得更猛烈些吧
    有志于预测的同学,建议看看红楼梦,娱乐一点可以先看刘心武老师在百家论坛的红楼梦探佚系列视频,很好玩

  119. 老刘 于 2010-05-10 11:37 下午

    受益匪浅!
    客客,要是能成的话,哥们要登门向你拜学。

  120. 理客 于 2010-05-10 11:41 下午

    to 老刘:太折杀兄弟了,我在海外,夏天可能会回京一次,但具体时间未定,如果您也在北京那个,如果到时候方便,我们可以见面交流

  121. 老刘 于 2010-05-10 11:43 下午

    客客,我在北京。

  122. 理客 于 2010-05-10 11:46 下午

    我的邮箱totobeing@hotmail.com,但工作忙的时候一、两天看一次邮箱,而不忙的时候又少

  123. 老刘 于 2010-05-11 5:07 上午

    据说,
    色情行业是网络带宽需求的主要推手。日本的AV行业够发达吧,没有光纤到户的宽带网络支撑,什么在线点播都是瞎扯。不是说iPad还没公开发售,就有色情公司找到apple商谈合作事宜吗?

  124. 老刘 于 2010-05-11 5:20 上午

    Y刚把话说完,
    Cavium就开始发布他们的32核的CN68xx多核处理器。
    40G产品。准备写篇评论。

  125. 理客 于 2010-05-11 6:42 上午

    32多核做40G,要好好探究一下什么条件下可以达到40G,期待老刘的作品

  126. sandwind 于 2010-05-11 7:37 上午

    cn68xx号称Q4 Sample, 估计实际11年Q2能出来就不错了。 如果还采用65nm, 功耗估计低不了。 短期还看XLP

  127. sandwind 于 2010-05-11 7:41 上午

    另外从应用上讲32核问题应该不大, 目前netlogic xlr其实从软件应用上也是32个处理单元, 很多客户都用了。

  128. 老刘 于 2010-05-11 7:48 上午

    这个32核CN6880功耗太高了-60W

  129. kakawolf 于 2010-05-11 5:12 下午

    请教下各位高手

    小弟正基于OCTEON CN5860做一个流量管理的毕设。目前的想法是data plane跑simple exec,control plane跑Linux l7filter做识别,将结果发回simple exec做流控。

    这样做适合吗,可以的话,有什么需要注意的难点?

    谢谢

  130. kevin 于 2010-05-11 5:33 下午

    毕设?一个人?跪拜。。。。

  131. picktracy 于 2010-05-11 6:13 下午

    看到这么多人在讨论Tilera,正好小弟前一段时间对Tilera网络部分做了评估,一些心得跟大家分享下。

    如果能在算法层面上保证并行度,并且合理利用Tilera的硬件特性,跑出来的数据会非常好看,性能与核数基本呈线性关系。

    上面很多人提到Tilera的Cache,不过貌似还没有说对/说全的。用户可以自己决定是否让硬件保证一致性,如果硬件提供保证,还分两种,Single Home-Tile和Hash-for-Home。IO的Cache也有Hash-for-Home,与前面稍有不同。

  132. 过客 于 2010-05-11 8:54 下午

    看来picktracy 对Tilera相当了解了。
    不错,对Tilera这种many-core来说,高并发的软件是很重要的,不过这对RMI是个坏消息,因为他做了很多帮助客户搞高并发的工作,要知道XLR732,XLP832都是32VCPU并发的,而Tilera的一个核相当于1.5或2个VCPU,这样在软件性能上是比较吃亏的,而且其Gx系列完全向cavium,RMI学习将网络应用所需的加速器都集成进去了,这对他们的威胁太大了,而Cavium,RMI要在core的数量上追上则需要迈过mesh这个坎,这是比较耽误时间的

    另外,虽然有不让硬件保持一致的开关,但是会有人用吗?

  133. julang3 于 2010-05-12 2:34 上午

    最近刚做完tilera的评估,其优点如下:
    1. 包处理性能非常强劲;10GE 三层转发,20个core即可实现;
    2. ZOL是tilera的一个创新,之前想过,但没能力去实现;
    3. 整体软,硬件均为包处理作了很多优化,NETIO编程库,MESH网络;

    缺点在于
    1. 不过处理DPI类应用,性能较同频X86还是要差不少;
    1. 缺少硬件的包分发引擎,目前需要使用部分core来做包分发;
    2.缺少硬件正则引擎,处理DPI类应用,需要完全使用软件来作内容匹配;
    这两点也是相比RMI,Cavium做得比较差的地方;

  134. boblee2000 于 2010-05-12 5:34 上午

    常来看看,很有长进啊,目前在用Cavium,但是对tilera很感兴趣,冒昧问下,哪位手头有tilera的MDE啊,能不能给我整一个研究下。

  135. fpeking 于 2010-05-12 5:48 上午

    思科买断Cavium和Ezchip?那某两个竞争对手就该哭了,新的chip都在用这些厂家的新东西。哈哈

  136. A 于 2010-05-12 6:03 上午

    弯曲感觉越来越没人气了。:-(

  137. boblee2000 于 2010-05-12 6:17 上午

    思科自己有NP的,不用买

  138. kakawolf 于 2010-05-12 5:08 下午

    哎,看来高手都很忙,没有时间搭理小弟。

    第一次接触cavium的处理器,为了毕业,现在硬着头皮也得上了

    神人们,高手们,有空还请出来说说啊

  139. 老刘 于 2010-05-12 6:14 下午

    To sandwind:

    XLP832出来了吗?没有吧?

  140. CNJ 于 2010-05-12 6:28 下午

    To kakawolf

    How do you plan to distribute the traffic? l7filter also need to see all data traffic in order to make identification decisions, right?

    Leave you IM or email that we can discuss more.

  141. zz 于 2010-05-13 12:56 上午

    从这里看xlp832貌似已经出来了。http://www.ccpu.com/atca-advancedtca-products/packet-pp80-dual-netlogic-xlp/

  142. sandwind 于 2010-05-13 2:30 上午

    根据目前了解的, XLP832应该还没有出来, 估计Q2能出来就不错了。

  143. kakawolf 于 2010-05-13 2:46 上午

    To CNJ

    谢谢!

    这是我的邮箱

    fdkdrk@126.com

  144. 黄岩 于 2010-05-13 6:26 上午

    今明两年是高端嵌入式多核CPU向45/40nm过渡期。

  145. picktracy 于 2010-05-13 6:08 下午

    To 过客兄,
    某些场景下用户自己管理Cache一致性对性能提升还是有帮助的。不过我对首席的次优解观点心有戚戚,从我的评估结果来看,“无脑”式开发依然可以跑得很高,Tilera的计算资源实在丰富。

    To julang3,
    如果某核没有其它负载,那么ZOL对性能提升微乎其微,可能更多的意义在于抗抖动等,不知道兄弟在ZOL上得到些什么结果。另外,Intel在其下一代平台中也引入类似概念。如果对硬件分包引擎很纠结,可以期待其GX芯片,不过国内市场貌似没货啊。。。

  146. samuel 于 2011-04-26 6:52 下午

    华为也在用Cavium,连X86都有了

  147. 胡不才 于 2011-04-26 8:19 下午

    可惜啊,要是当时一个集团军进去,首席就可以退休了

  148. 理客 于 2011-04-27 12:47 下午

    首席已经是可退休而不休的rich man了,创造力的活性需要自由+竞争的环境和衣食无忧,所以首席更看好90后比之前的0后们更有可能代表中国未来的核心竞争力

  149. WR 于 2011-04-27 9:33 下午

    这个听不了了,还能上哪儿找到这段音频么?

  150. ivan 于 2011-05-01 5:19 上午

    在哪还能找到这段音频?

  151. filerluo 于 2011-05-10 3:38 上午

    同楼上,在哪能找到这段音频?

  152. softarts 于 2011-05-19 7:38 上午

    为什么音频没了?

  153. anonymous 于 2011-12-06 12:20 上午

    同求音频啊!!!!!!

  154. 真不明白 于 2011-12-14 6:02 上午

    看了不少,说白了陈慧琳就是个很牛逼的二笔

  155. mark 于 2012-03-17 1:29 下午

    首席承诺的开源项目呢?