《关于新一代操作系统的思考》
作者 陈怀临 | 2016-10-02 20:12 | 类型 中国系统软件 | 3条用户评论 »
包云岗 。《科研指挥棒怎么挥舞》
作者 陈怀临 | 2015-04-07 10:45 | 类型 中国系统软件, 科学与中国 | 1条用户评论 »
魏永明 。 “自主”操作系统 (完)
作者 陈怀临 | 2012-09-23 00:36 | 类型 中国系统软件 | 20条用户评论 »
4 如何开发“自主”操作系统4.1 开发“自主”操作系统的两种目的和策略开发“自主”操作系统的主要目的有两种:一种是想再造一个类似 Android、iOS 的操作系统,并作为其竞争者;一种仅仅是为了在商务谈判和合作中获得一个比较好的筹码。当然,还有一种目的就是骗取政府的财政支持,对这类不良目的,不属本文讨论范围。 我们先猜度一下国内外这几年出现的一些“自主”操作系统,其目的是什么:
好,面对这两种开发“自主”操作系统的目的,应该有什么样的策略呢?其实策略很简单,不管你是真心还是假意,都应该按照本文第 3 章给出的“自主”操作系统之特征进行开发,除此之外,别无他法。任何期望找捷径的方法,都不可能获得成功。这里所说的找捷径的方法具体有:
顺便谈谈我对基于浏览器技术的 web 操作系统之看法。 理论上讲,浏览器可以做很多事情,甚至可以替代 PC 机上的通用操作系统。但是,最新的浏览器技术(HTML5/CSS3等),还存在一些技术上的问题。主要的问题有如下两个:
HTML5 技术作为原生应用的一种补充,可以起到很好的作用,但是,如果要想在浏览器技术上建立一个真正可以和 Android 等竞争的操作系统,恐怕还需要很长的时间(技术上必须有突破)。要不然,Google 现在主推的应该是 ChromeOS,而不是 Android。 现在回答刚才提到的问题:“为什么 FirefoxOS 可以比 webOS 的生命力更加长久些呢?”主要的原因是,FirefoxOS 是开源的,有比较强大的企业在主导其发展,作为一个脱胎于开源基金会的企业(Mozilla公司),也能获得合作伙伴的一些好感;相反,因为 webOS 是封闭,HP 又没有能力像苹果那样打造一个完全封闭的平台和生态系统,所以最终的命运是被人抛弃了。虽然后来 webOS 也走上了开源的道路,但大势已去,HP 不亲自带头搞,光靠开源社区是搞不成的。 4.2 技术层面上的考虑假定你是一名“自主”操作系统项目的技术管理者,你第一步要考虑的问题是什么?许多人的回答可能是:先选操作系统内核、基础库什么的。其实错了,第一步要考虑的应该是你打算选择什么编程语言作为原生应用的编程语言。 世界上的编程语言有很多种,有些语言贴近机器,比如汇编语言、C语言,有些语言贴近人,比如 Basic、Java,还有些语言用于特定领域,比如网页服务器端使用的 PHP,有些适合做不同软件之间的粘合剂,比如 Perl、Python。本文第 3 章已经解释了编程语言以及围绕编程语言形成的运行环境、框架是将操作系统区隔于其他操作系统的主要技术特征。因此,我们必须慎重选择一种编程语言。而且一旦选定了一种编程语言,“自主”操作系统在开发者看来长什么样,其实就基本上定了。 选择编程语言要考虑如下因素:
其实很多读者看到这里,都会想到 Java 语言。是的,Java 语言或其派生语言如 C# 是构架“自主”操作系统的最佳编程语言。可惜,已经被 Android 和 Windows Phone 给捷足先登了。 如此一来,你可以考虑重新设计一门类似 Java 的语言,也可以通过其他手段,让你使用 Java 语言构建的操作系统有别于其他操作系统。比如,构建自己的虚拟机,如 Android 使用的 Dalvik 那样(Dalvik 和 Oracle 的 JDK 标准虚拟机有很大不同,从而让 Oracle 还挺难告赢 Google 的);你也可以用 Dalvik,但让类库、运行环境和 Android 不同(这样做的法律风险要大一些)。总之,你需要有自己的创新,全部抄袭是不行的。 确定了编程语言,接下来的工作其实就比较直接了,从上而下设计就是了。主要有:
上面的第一点和第二点,是“自主”操作系统有别于其他操作系统,且支撑你可以和其他人竞争的关键点。往下的东西都不是构成“自主”操作系统真正竞争力的东西。 这么看来,其实也挺简单的。不是吗?貌似有钱、有个把技术上的明白人就能做到。技术上没问题了,市场、法律等方面的事情,请专业人员帮忙,中国这类人才还是蛮多的,缺的,其实还是技术人员以及懂系统工程和软件开发的管理人员。 4.3 快速搭建一个“自主”操作系统这里给大家介绍笔者早先和美国一家公司合作,尝试搭建的一个操作系统,其实在当年这些东西的基础上,搭建出来一个有别于 Android 的开源“自主”操作系统还是非常快的。 这个系统使用了 Linux 内核和标准的 C/C++ 函数库,以及一些和 Android 体系结构类似的 C/C++ 运行库,使用了笔者公司的开源软件 MiniGUI、WebKit 浏览器核心引擎等等。基础的东西就这些。之上是开源的 Kaffe JVM(后来改成了 Cacao JVM),和符合 J2SE 规范的类库实现,再往上就是运行环境和框架了。见下图: 可惜的是,真正具有核心价值的运行环境和框架,是美国合作方自己开发的,我手里没有源代码。相信读者也能明白,美国合作方掌握的才是精华。 | |
淘宝网内核开发团队盼寻有缘分的在校实习生
作者 网络菜鸟 | 2011-11-19 10:11 | 类型 中国系统软件, 互联网, 工作机会 | 35条用户评论 »
淘宝内核组是一只非常年轻的队伍,我们作为开源社区和淘宝的桥梁,一方面基于淘宝的工作负载来改进Linux内核的性能和质量,另一方面也将开源社区的新想法引入到淘宝的操作系统运行环境中。我们在不断改进Linux在淘宝成千上万台服务器上运行的性能和稳定性的同时,也持续努力将我们的工作反馈回开源社区。 关于淘宝内核组的简单情况介绍,可以在这个wiki页面看到:http://kernel.taobao.org 对于我们在内核社区的一些还很初级的工作,在这个wiki页面有一些简单的数字:http://kernel.taobao.org/index.php/Documents/kernel_development_at_taobao 我们和国内、国际的同行一直有紧密的合作,同时我们的工作内容对开源社区也非常开放。在这个小团队工作,可以同我们一起体验如何从线上运行的上万台服务器的实际运行数据中寻找可以改进Linux内核的想法,然后付诸实践并通过实际运行数据来验证自己的工作效果,并最终将代码反馈回内核社区的这个过程。 如果你是在校的学生,对系统软件开发有一些了解,而且有热情投入到Linux内核开发的社区中来,也许你可以考虑加入到淘宝内核组这个小团体中来进行实习工作。我们是非常年轻的团队,但是我们是勤奋、认真和努力的一小撮人。 实习的工作地点在杭州或者北京的淘宝办公室,根据大家的意向而定;工作时间要求不短于3个月,每周不少于3天。我们的实习工资很平常,够路费和伙食费。只是希望在这里做过实习工作的同学以后回忆起这段经历会依然感觉很开心。 欢迎有兴趣的同学发邮件到 bosong.ly 在 taobao 点 com ,希望我们能够有缘分在一起度过一段值得回忆的时光。 P.S. 如果同学们毕业之后,不论是否加入淘宝的工程团队,只要能够兴趣参与到Linux内核开发和开源社区中来,这个实习生计划就是成功的。 | |
淘宝开源的PB级分布式数据库系统OceanBase简介
作者 zhuyanhai | 2011-08-31 15:18 | 类型 专题分析, 中国系统软件, 云计算 | 13条用户评论 »
[ 编者注: OceanBase是一个支持海量数据的高性能数据库系统,实现了数千亿条记录、数百TB数据上的跨行跨表事务,由淘宝网核心系统研发部、运维、DBA、广告、应用研发等部门共同完成。其源代码已于8月31日遵照GPL2开源。 本文第一部分转载于淘宝网核心系统研发部博客, 原始链接位于http://rdc.taobao.com/blog/cs/?p=956 第二部分转载于OceanBase主程序员杨传辉同志的个人博客 , 原始链接位于 http://www.nosqlnotes.net/archives/tag/oceanbase OceanBase的源码可于http://code.taobao.org/project/view/587/ 处得到] OceanBase是什么OceanBase是一个支持海量数据的高性能数据库系统,实现了数千亿条记录、数百TB数据上的跨行跨表事务,由淘宝核心系统研发部、运维、DBA、广告、应用研发等部门共同完成。 OceanBase解决什么问题许多公司的核心资产是各种各样的商业数据,例如淘宝的商品、交易、订单、购物爱好等等,这些数据通常是结构化的,并且数据之间存在各种各样的关联,传统的关系数据库曾经是这些数据的最佳载体。然而,随着业务的快速发展,这些数据急剧膨胀,记录数从几千万条增加到数十亿条,数据量从百GB增加到数TB,未来还可能增加到数千亿条和数百TB,传统的关系型数据库已经无法承担如此海量的数据。许多公司,尤其是互联网公司,正在探索各自的解决之路。 OceanBase的一些基本概念OceanBase逻辑架构简图主键row key,也称为primary key,类似于DBMS的主键,与DBMS不同的是,OceanBase的主键总是二进制字符串(binary string),但可以有某种结构。OceanBase以主键为顺序存放表格数据 sstable一种数据存储格式,OceanBase用来存储一个或几个表的一段按主键连续的数据 tablet一个表按主键划分的一个(前开后闭的)范围,通常包含一个或几个sstable,一个tablet的数据量通常在256MB左右 基准数据和动态数据OceanBase以增量方式记录一段时间内的表格数据的增删改,从而保持着表格主体数据在一段时间内相对稳定,其中增删改的数据称为动态数据(通常在内存,也称为内存表),而一段时间内相对稳定的主体数据称为基准数据,基准数据和转储后(保存到SSD固态盘或磁盘)的动态数据以sstable格式存储 ChunkServer保存基准数据的服务器,通常是多台,为了避免软件硬件故障导致的服务中断,同一份基准数据通常保存了3份并存储在不同ChunkServer上 UpdateServer保存动态数据的服务器,一般是单台服务器。为了避免软件硬件故障导致的服务中断,UpdateServer记录commit log并通常使用双机热备 MergeServer进行静态动态数据合并的服务器,常常与ChunkServer共用一台物理服务器。MergeServer使得用户能够访问到完整的最新的数据 RootServer配置服务器,一般是单台服务器。为了避免软件硬件故障导致的服务中断,RootServer记录commit log并通常采用双机热备。由于RootServer负载一般都很轻,所以它常常与UpdateServer共用物理机器 冻结指动态数据(也称为内存表)的更新到一定时间或者数据量达到一定规模后,OceanBase停止该块动态数据的修改,后续的更新写入新的动态数据块(即新的内存表),旧的动态数据块不再修改,这个过程称为冻结 转储出于节省内存或者持久化等原因将一个冻结的动态数据块(内存表)持久化(转化为sstable并保存到SSD固态盘货磁盘上)的过程 数据合并(merge)查询时,查询项的基准数据与其动态数据(即增删改操作)合并以得到该数据项的最新结果的过程。此外,把旧的基准数据与冻结的动态数据进行合并生成新的基准数据的过程也称为数据合并 联表(join)一张表与另一张或几表连接的关系,类似于DBMS的自然连接 COWCopy on Write的缩写,在OceanBase中特指BTree在更新时复制数据备份写入,避免系统锁的技术手段 OceanBase有什么特点OceanBase设计和实现的时候暂时摒弃了许多不需要的DBMS的功能,例如临时表,视图(view),SQL语言支持等,这使得研发团队能够把有限的资源集中到关键的功能上,例如数据一致性、高性能的跨表事务、范围查询、join等。
上述的DBMS和云计算技术的优势互补使得OceanBase既具有传统DBMS的跨行跨表事务、数据的强一致性以及很短的查询修改响应时间,还有云计算的海量数据管理能力、自动故障恢复、自动负载平衡以及良好的扩展性。 OceanBase现在有什么应用OceanBase现在已经应用于淘宝收藏夹,用于存储淘宝用户收藏条目和具体的商品、店铺信息,每天支持4~5千万的更新操作。后续将陆续推广至其他淘宝应用。 OceanBase的创新之处在哪里?ppt已上传到Slideshare上。 从大学的数据结构课程可以知道,数据量比较大时,有两种数据结构很常用:哈希表和B+树,分布式系统也是类似的。如下图: Amazon的系统实现了一个分布式哈希表,而Google Bigtable, Yahoo PNUTS,Microsoft SQL Azure实现了一颗分布式B+树。分布式哈希表实现相对简单,但只支持随机读取;而分布式B+树支持范围查询,但实现比较复杂,主要有两个难点: 1, 状态数据的持久化和迁移。更新操作改变系统的状态,数据库系统中更新操作首先以事务提交日志(MySQL称为binlog, NOSQL称为commit log)写入到磁盘,为了保证可靠性,commit log需要复制多份并保证它们之间的一致性。另外,机器宕机时需要通过commit log记录的状态修改信息将服务迁移到集群中的其它节点。 2, 子表的分裂和合并。B+树实现的难点在于树节点的分裂与合并,在分布式系统中,数据被顺序划分为大小在几十到几百MB大小的数据范围,一般称为子表,相当于B+树结构中的叶子节点。由于每个子表在系统中存储多份,需要保证多个副本之间的分裂点是一致的。由于子表在分裂的同时也有更新操作,保证多个副本之间一致是比较困难的。 对于这两个问题,不同的系统有不同的解决方法: 1, 状态维持。Google Bigtable将状态数据写入到GFS中,由GFS提供可靠性保证,但GFS本身是一个巨大的工程;Yahoo PNUTS将状态数据写入到分布式消息中间件,Yahoo内部称为Yahoo Message Broker;Microsoft SQL Azure直接通过网络将数据复制到多机,由于一台机器服务多个子表,这些子表的副本可能分布在整个集群中,因此,任何两台机器都可能建立数据复制的网络通道,需要处理与这些通道有关的异常情况。 2, 子表分裂。由于底层有GFS保证可靠性,Google Bigtable设计时保证每一个子表同时只被一台机器(Tablet Server)服务;Yahoo PNUTS通过引入复杂的两节点提交(Two-phase commit)协议协调多个副本之间的一致性,使得他们的分裂点相同;Microsoft SQL Azure干脆不支持子表分裂,牺牲一部分扩展性从而简化系统设计。 淘宝Oceanbase设计之初对淘宝的在线存储需求进行分析发现:淘宝的数据总量比较大,未来一段时间,比如五年之内的数据规模为百TB级别,千亿条记录,另外,数据膨胀很快,传统的分库分表对业务造成很大的压力,必须设计自动化的分布式系统;然而,在线存储每天的修改量很小,大多数情况下单机的内存就能存放下。因此,我们采用将动态数据和静态数据分离的办法。动态数据的数据量小,采用集中式的方法解决,这样,状态数据维持从一个分布式的问题转化为单机的问题;静态数据的数据量大,采用分布式的方法解决,因为静态数据基本不变,实现时不需要复杂的线程同步机制,另外,保证静态数据的多个副本之间一致性是比较容易的,简化了子表的分裂和合并操作。通过这样的权衡,淘宝Oceanbase以一种很简单的方式满足了未来一段时间的在线存储需求,并且还获得了一些其它特性,如高效支持跨行跨表事务,这对于淘宝的业务是非常重要的。另外,我们之所以敢于做这样的权衡,还有一个重要的原因:我们内部已经思考了很多关于动态数据由集中式变为分布式的方案,即使我们对需求估计有些偏差,也可以很快修改原有系统进一步提高可扩展性。 | |
Java 程序的编译,加载 和 执行
作者 coder | 2011-07-28 19:17 | 类型 中国系统软件, 行业动感 | 2条用户评论 »
[ 在这个 slides 里边, 莫枢 (Kris Mok) 介绍了 java & java run-time system 的结构。Managed language 提供了更高一级的抽象,提高了程序员的生产力,但是从 application code 到 ISA 的中间层也更厚,比如程序员非常容易把C代码对应到优化后的汇编,但是判断出java 程序对应的汇编就相对难一些。胶片作者的blog 是 http://rednaxelafx.iteye.com ] | |
弯曲学术:Steve Blackburn 在清华的讲座
作者 coder | 2011-04-14 17:35 | 类型 中国系统软件, 行业动感 | 4条用户评论 »
(Steve 去北京旅游,我忽悠他去清华 give a talk, 有兴趣的朋友欢迎来围观。) Steve Blackburn 4 月 29 号上午9:50~12:00,在清华 FIT楼 1-312 会议室 give a talk。 谁是 Steve Blackburn? Stephen Blackburn is an Associate Professor in the Department of Computer Science at Australian National University (http://users.cecs.anu.edu.au/~steveb/). His research focus is on programming language implementation, and in particular the performance of modern programming languages on modern architectures. He is interested in understanding, measuring and addressing the narrowing memory bottleneck, and the characteristics of modern languages and architectures that exacerbate this problem. His service includes program committees and external review committees such as ASPLOS, ISCA, OOPSLA, ISMM, VEE, and PLDI, and the program chair of ISMM 2008. He has led the development tools and benchmarks in wide use: the MMTk garbage collection toolkit and the DaCapo Java Benchmarks. He is on the Jikes RVM Steering committee and leads the DaCapo Benchmark Suite consortium.
他会讲神马? Title: Looking Back on the Language and Hardware Revolutions: Measured
| |
Multicore 的烦恼
作者 coder | 2010-07-20 15:00 | 类型 中国系统软件 | 28条用户评论 »
【编者注:这个文章是超级大学霸 David 在 IEEE SPECTURN 上写的一个描述我们整个计算机系统 big picture 的文章。 我把其中主要的论点描述一下,有兴趣懂同学直接看就是了。首先在这里需要实现说明的一个非常重要的背景就是:“Multicore 并不是我们主动选择的路,而是我们不得不选择的路!。” 非常多的人没有搞清除这个基本概念,甚至有些博士僧也没搞清除。 首先学霸老爷回顾了1975年的一场比赛,达拉斯牛仔的四分卫合着眼把球传了出去。他希望有人能接著这个球。现在的 multicore 就是 computer system 的四分卫 ( intel 等) 合着眼传出的球。为什么他们这么干,两个原因 1) power wall 2)我们still还能放更多的 transistor 放到die 上。 然后四分卫们撂挑子了,以后我们只管堆core(我只能吧球传远点,就是说我以后不动脑子了,只练力量), 你们要不要更快(try),随便。 四分卫把球传出来,能不能try 就靠我们小码农的了。如果身为码农的你写过大规模并行程序,那你应该知道这个 try 有多难!估计大部分码农 memory consistency 都还没弄明白了就被告诉必须给个100core 的 CPU写程序。苍天阿。 各种风花雪月的自动并行,自动优化研究就开始了。烧钱阿!学霸举了几个成功例子:transactions, 科学计算 和 图形图像。 为啥他们成功了?逻辑简单,没有依赖。不过即便是逻辑简单,没有依赖,要想弄个牛系统,你还得找牛程序员。 在悲观的同时,学霸还是指出了曙光: 第一点:四分卫合着眼睛传的,你们要是想try 自己去拼。我不能老是给你们传那些漂亮球了!码农们会积极主动的学习 memory consistency model. 第二点:云计算。云端的码农辛苦些。同时降低依赖,很好并行。比如同时开4个kvm在一个机器上。 除了这两点,为了证明不是岳不群, 身为学霸的 David怎么也得在危机时刻拯救世界阿,要不以后小弟们来打假怎么办。学霸深的两手都要抓,两手都要硬的 传统 中华智慧!一边开始狂优化一些 kernels. 操作系统同学们不要机动。这个不是操作系统kernel。狂优化的 操作系统 kernel 已经被首席给屠了。这个 kernel 是指的一些常用的应用和计算非常重要的基本计算方法。 那学霸的另一只手伸向哪里了呢?不要想歪了,对,是 大规模multicore design。 就是传说中的 RAMP project。 拿FPGA simulate 100 个以上的 core。 why? 两个目的: 1) 给四分卫们做做示范,挖挖散兵坑。 2)做软件的很懒的。你在 simic 上 boot 过 linux 吗? 你在 PTLsim 上跑过程序吗? 在 PTLsim 上跑个 Eclipse benchmark 要多半个星期。我们码农的宗旨就是没有硬件绝不提前开发软件。学霸把这个搞出来,好给码农们说你们Y没理由了吧,快好好干,别整天下午茶。 ] | |
陈怀临时间–浅谈网络服务处理器(NSP)
作者 陈怀临 | 2008-12-22 12:12 | 类型 中国系统软件, 弯曲推荐 | 6条用户评论 »
【相关文章】: | |
路由器需要多大内存?
作者 黄 岩 | 2008-12-16 15:34 | 类型 中国系统软件, 弯曲推荐, 通讯产品 | 11条用户评论 »
计算机需要多大内存?当然是越大越好了,这是用户的想法。但是计算机的设计者则必须在成本、实现难度、和取悦客户等几个因素之间进行折中,选取一个最佳平衡点。对计算机来说,其主要依据是产品的市场定位,高端商务PC至少配2G内存,低端学生机配256M就够了。如果用256M RAM的学生机来作复杂的大规模FPGA仿真,可能会发现硬盘的灯一直是亮的,这说明内存已经不够用了,操作系统正在不停的在内存和硬盘之间兑换数据,用大容量的低速硬盘来弥补内存太小的不足,但是代价是计算时间延长了很多倍。路由器是不是也向PC一样,主要依据售价来决定内存配置的大小呢?会不会也是内存越大越好呢?路由器的设计者依据哪些因素来决定内存配置的大小?一般来说,路由器的内存主要用于一下这些方面: (1)用于存储路由器软件指令和静态数据,路由器跟PC不同,PC是只把当前运行的程序装到RAM中,但多数路由器都是一开机就把全部程序都装到RAM中,一般来说,路由器的程序也不大(几兆到几十兆);(注:此处主要指控制平面的程序,也就是Cisco和Juniper的路由引擎) (2)用于存储动态数据,例如:路由表、OSPF的链路状态数据库等。假如某路由器需要支持最多10万条路由,按照每条路由256字节计算,那么大约需要200M左右内存。 (3)用于缓冲数据报文,路由器的工作原理是存储转发。极端情况下,路由器的每个接口,至少需要缓冲一个报文,否则路由器根本不能工作。下面重点讨论这个问题。 一般来说,路由器配置的报文缓冲区都不止一个报文。因为这样也就意味着当有新报文到达的时候,如果前面一个报文正在发送,这个报文缓冲区尚未处于空闲状态,那么新的报文势必将会被丢掉。等前面一个报文发送完了,链路处于空闲状态,但是由于刚才报文已经被丢掉了,也无法利用链路空闲状态。如果被丢掉的报文是TCP报文,那么主机势必将重传这个报文(在该路由器前面的一段线路上传输两次同样的报文),并缩小自己的发送窗口,降低了TCP连接的速率。 也就是说,如果接口的报文缓冲区太小,将导致丢包率高,数据链路利用率低,TCP传输效率低。那么是不是报文缓冲区越大越好呢?也不是,因为报文缓冲区大到一定程度,就不能继续提高数据链路利用率和降低丢包率了。如果这台路由器处于拥塞状态,接收报文的速率远远大于接口的发送带宽,无论多大的报文缓冲区都会被填满,而报文缓冲区大了,那么也就意味着拥塞状态的时候,报文的转发延迟时间会很长。延迟时间太长的报文,对于接收方来说,已经没有意义了。以TCP连接为例,当报文大于发送方的重传时间的时候,发送方就会重传该报文,也就是说,大于TCP的重传时间的到达的报文,是没有意义的。对VoIP等应用来说,对网络延时更加敏感。 一般来说,路由器的接口缓冲区的大小有一个经验法则(rule-of-thumb):B = C * RTT,C是链路速率,RTT是平均报文往返之间。至于这个经验法则源自哪里,我没有认真考证。但这个经验法则的主要依据是最大化TCP效率,最大化网络接口带宽利用率。如果依据这个法则来设计路由器,对中低端路由器来说,问题不大。但是对于高端路由器,是有挑战的。一般中高端Internet骨干路由器上会假设RTT为250ms,那么对于个10GE接口,需要的内存是(10G bit/s * 0.25 s) / 8 约为300MB。也许大家会说,300M不大么,但是可以预见,最近两年核心路由器的容量必将发展到单槽位80 - 160G,也就是说单大约需要2.5G - 5G内存。虽然不是完全不可实现,但还是有一定难度。从Juniper的一个白皮书(Characteristics of Switches and Routers)可以看出,Juniper也是按照这个经验法则设计的。 但是最近的一些研究认为(sizing router buffers, Guido Appenzler, Isaac Keslassy, Nick McKeown),其实路由器不需要那么大的内存,每个端口只需要缓冲几十个报文就足够了,这样用NP或ASIC内嵌的RAM就够了,不用配置外部RAM。他主要依据是以前的经验法则是根据单TCP流来推算的,作者认为这个模型不对,实际的骨干路由器上是有很多TCP流的,因此应该按照B = C * RTT / sqrt(N)来计算,N是TCP流数量。但是另外一些研究则认为这个结论不对,路由器上不能只考虑TCP,还有很多急于UDP的语音和视频应用。反正在教授们之间,这个问题至今仍然没有一致的意见。工程师已经不再争论这个问题了,就按照B = C * RTT来设计,成本可以接受,而且也比较安全:) | |