谷歌网络的贼船,你还想上?
拜读了一下夏老师在HPCA发表的关于NOC的论文,简单的评价就是:干净/漂亮. 同时正好网工的圈子都在转谷歌在NSDI上发表的Aquila,只能说差强人意吧,好的地方是给的数据中心网工们一个折腾的空间,但总觉得有点太复杂其它公司无法食用,而且感觉就是离应用太远了。
总体来看NOC+DCN两篇一起看懂了说明书服用疗效更佳,因为在去年曾经写过一个东西
<云网融合的探索>
华为基于应用定义的NOC
看大师的论文,一般来说一看标题< Application Defined
On-chip Networks for HeterogeneousChiplets
: An Implementation Perspective >就知道这玩意有戏了, 文章一开始就讲清楚了一个道理
三者不可兼得,对于Server-CPU很大程度上是延迟敏感的并且需要严格的处理tail-latency,而针对AI的场景是带宽敏感的,同时从架构上又需要有足够的表现力(原文为Expressiveness),但是你又不得不考虑冯机的大量的应用如何同DSA交互编程的问题,而最后就是物理实现的问题,片上网络的布线和功耗。然后还有一个关键的问题Cache-Coherence怎么搞?某司当年做网络处理器的时候就是简单粗暴,没Coherence的需求不搞,甚至连L2-D都么有.但是夏老师讲的很清楚,他们是做通用处理器的,所以stick to the shared memory abstraction无可厚非(渣也表示赞同,毕竟通用处理器还需要面对大量的普通程序员的代码,易于使用比什么都重要)
让人眼前一亮的就是这个图,简单、干净、漂亮的解决方案
把Cache这么玩,渣的内心想法就是:“艹,我怎么没想到”,通用CPU L3-Tag和L3-Data的分离做的太漂亮了,而同样的方式针对AI处理器的L2$分撒在NOC上,再加上RBRG以及非常简单的I-Tag、E-Tag机制,干净简洁。
你看上面这图,Cache Access的延迟和L3Cache大容量和带宽,特别是per-core能够使用的带宽一下子就上去好多,同时连接I/O的die也非常简洁高效,一个Ring Bridge就完事了。所以我一直善意的提醒国内某个做多核ARM的DPU厂商,你们Memory Subsystem有问题,因为ARM自己的那套NOC讲真我觉得不舒服,可惜人家就是不听还要犯一次当年XLR的错误才会懂。
谷歌Aquila
首先业务的需求是要在公有云上跑HPC,这是很多企业未来几年的刚需,也是公有云业务的增长点,但是呢对于公有云又不想两张网来搞,然后卖螺丝的网卡和TOR交换机也贵,然后很多普通的HPC业务例如CFD一类的通常对于延迟更加敏感,而RoCE一类的又有各种各样傻X的问题,然后HPC计算又可以有很好的局部性处理,但是传统的TCP各种事情又搞不定。
以上这是Aquila的前提,但请注意这是一个实验性质的网络,和Google以往的作风不同的是,它并没有像以前那些大作一样商用几年了再来把其它厂家按在地上摩擦,同时它并不能简单的泛指下一代数据中心网络,当然国内的网工们呢可以用抄作业为名暂且避过互联网的寒冬,问题是你们的运维能力和实施能力离谷歌肯定还有一些差距,这个时候一些设备厂商的Vendor(说的就是BRCM、Cisco以及国内一些DPU厂商)能不能顶上呢?
总体来说的设计就是针对HPC的局部超低延迟通信需求,构建的一个拓扑,然后为了和一些美国国家级的EFLOPS超算抢生意,所以拓扑也采用了DragonFly
然后为了消除抖动(更明确的说是尾延迟),采用了信元路由的机制,信元头是8B,由pod-id、TiN id和Endpoint-id编码, 16bits的SRC、DST、Cell-Length、VC、TTL、8bits CRC和Trace Enable bit,然后每个TiN都有信元路由的能力,信元最大160B,看上去觉不觉得这是一个大号的ATM?然后Deadlock避免机制用了VC,说实话我很讨厌这玩意,说不出来为啥就是觉得不舒服。
然后整个芯片呢是一个100GE以太网MAC和32个28Gbps Serdes以及2个PCIe3.0组成的
虽然他们称这东西是一个ASIC,但是我觉得Google应该不会为一个实验性质的东西去流片,而且从这些参数来看,感觉可能一个Xilinx KU15P就能放下这些逻辑(可以参考思科的Nexus 3550低延迟交换机),然后做几个PCB应该整个成本不算太高
而控制器呢,沿用了以前的Orion
敲黑板,分布式控制器,具体的分析见下文
<Google Orion:终于SDN走到了分布式控制器时代>
而对于信元的发送和接收,片上有相应的Ingress和Egress的Buffer,然后通过RTS/CTS信号控制收发及信元重组,调度算法上当然还是在用Nick教授20多年前给Cisco GSR设计时用的iSLIP算法以及一些weighted的增强,总体来说就是实现了多路径的adaptive route
但是至于这个CostEffective,省了网卡的钱,整合进TOR了,但是布线的钱和维保的运营开销呢?
非以太网的东西本来各种器件的价格就会高蛮多的,所以你看AWS SRD和我自己做NetDAM一定是underlay要用以太的,特别是在更高速的场景里,延迟肯定会进一步增加,感觉这事情做的有点过了,当然毕竟是一个研究实验性质的网络嘛,然后又要搭DragonFly的拓扑,可以理解。
从另一个方面来看,这是一个很好的TOR的实践,把网卡从主机再一次剥离出来,直接PCIe到TOR
你可以看到思科自己的UCS-X也在玩类似的事情,
背板有相应的PCIe、CXL交换的空间,并且也把网卡和背板集成在一起了
局部来看,为了降低延迟更加的紧耦合是有必要的,但是这么做总觉得有些不干净,因为这玩意是延迟低啊,但是带宽大了主机的DMA内存墙的问题依旧没有干净的解决,虽然有Snap这样的软件系统去辅助,但是使用效果对于通用的云计算来讲还是相对。。。
另一方面,这个工作和真正的AI团队又是有一定距离的,总觉得Aquila是一个KPI的项目,而真正的重心和值得关注的还是在TPU集群和Pathway这样的东西上,那些才是未来变革的力量。
结语
很多时候吧,外国的月亮不一定圆,谷歌这个东西吧还是太网络团队了,和应用离得远和底层NOC离得远,两边都不讨好,还搞得特别复杂。而夏老师他们做的东西简单、应用直接爽到了,所以建议大家要有一些架构上的自信。
对谷歌Aquila感兴趣的同学点个赞和在看后,在公众号后台回复“Aquila”可以获取相关下载。
相关文章
- 在 Go 里用 CGO?这 7 个问题你要关注!
- 9款优秀的去中心化通讯软件 Matrix 的客户端
- 求职数据分析,项目经验该怎么写
- 在OKR中,我看到了数据驱动业务的未来
- 火山引擎云原生大数据在金融行业的实践
- OpenHarmony富设备移植指南(二)—从postmarketOS获取移植资源
- 《数据成熟度指数》报告:64%的企业领袖认为大多数员工“不懂数据”
- OpenHarmony 小型系统兼容性测试指南
- 肯睿中国(Cloudera):2023年企业数字战略三大趋势预测
- 适用于 Linux 的十大命令行游戏
- GNOME 截图工具的新旧截图方式
- System76 即将推出的 COSMIC 桌面正在酝酿大变化
- 2GB 内存 8GB 存储即可流畅运行,Windows 11 极致精简版系统 Tiny11 发布
- 迎接 ecode:一个即将推出的具有全新图形用户界面框架的现代、轻量级代码编辑器
- loongarch架构介绍(三)—地址翻译
- Go 语言怎么解决编译器错误“err is shadowed during return”?
- 敏捷:可能被开发人员遗忘的部分
- Denodo预测2023年数据管理和分析的未来
- 利用数据推动可持续发展
- 在 Vue3 中实现 React 原生 Hooks(useState、useEffect),深入理解 React Hooks 的