随便谈谈网络通讯延迟和应用

首先丢出2个简单定理。
 
定理1
任何所谓的软件编程本质上都是面向硬件编程
 
定理2
任何软件操作的根本延迟受制于硬件循环所需要的时间
 
计算机作为一个输入输出设备,本质上就是3个步骤,输入、处理、输出。计算机之间的通讯媒介,无非有线无线,其实主要是取决于介质和通讯方式。
 
如果是有无线的场合,包括WiFi或者是无线电RF还是所谓的5G,都在这个范畴。WiFi存在Jitter,这个延迟必须考虑在内,一般会考虑多个WiFi的NIC提高带宽减小延迟。民用无线电技术如今可以做到40Gbps的带宽不是问题,延迟也较低,但是这个容易有干扰,还需要无线电执照许可,比如无人机都用WiFi的公共频段,所以机器在某个场合聚集就都废了,而且干扰技术也压根不存在问题。
 
有线,只要是基于电的,那都逃不过物理定律,非超导的常温状态下,联系到基本电磁干扰和信号衰减,距离做到百米级别,带宽做到10Gbps已经是极限。需要比如10Gbps以上的带宽往往都是光纤接口。这个好处是简单粗暴,买硬件设备和电缆就行。
 
但是,有些场合是不需要考虑延迟的,而是需要可靠性的,比如HTTPS的响应。TCP加上TLS这一层,这个其实是怎么都不会快的,对于一个看网页的用户来说,100ms和200ms的响应,是没几个人会抱怨的,通过CDN等等可以优化吞吐到很理想的状态,也就是小于100ms,接近于本地的的速度。这个WiFi的好处就是随处可得,问题是搞延迟低吞吐。
 
如今的Web应用,从TCP/IP模型看,主要是第4层应用层的折腾,IP层都不会考虑,靠买设备解决。我称之为延迟在100ms以下的应用。这个往往都是通过CDN来,但是也不会小于15ms。本质上还是堆设备以及在现有的TCP/IP的第3层上捣鼓,优化路由优化连接,以城市为单位部署更多的节点诸如此类。
 
但是要记得,15ms是一个很高的延迟。为什么这么说,因为15ms几乎是现有互联网跨地域应用的一个极限,也就是无论是你玩游戏也好,所谓的低延迟视频的也好,所谓的低延迟实时数据分析也罢,这个延迟对于现有GPCPU(看清楚,不是GPCPU)来说,都逃不过定理2——就是说,你怎么折腾,从NIC触发中断,然后Kernel再来折腾,然后再来通知Userspace的程序去处理,如果是转发的话这个再来一遍,这个过程已经消耗了许多CPU循环,而且许多操作跟数据处理本身并无关联。当然可以打一下Realtime Linux内核补丁,但是从根本上来说,这些步骤都需要进行,都是基于现有的硬件之上,所以本质上也没什么意义。看到搞什么Apache Spark+Kafka的就觉得搞笑,就这些Java堆起来的大路货,最多做做Web应用,在核心关键场合,这些都统统得废。
 
当你在本地跑个NodeJS,本地发个HTTP请求,那个已经最少1ms,这个就是单个PC工作站能做到的极限——跑了一圈应用程序的Runtime,到OS API,外加TCP/IP Stack,然后返回结果再重新跑一轮。在异步编程还没流行的时代,服务器的表现其实也并没有太差劲,而且同步网络编程好写逻辑。但是归根结底,无论同步和异步,都是仰仗硬件架构加上OS的核心API提供给上层。应用程序得益于多线程使得逻辑和网络发包线程可以分开,但是其实只是充分利用了系统的间歇性存在的资源,和本质上的提高并无相关。也就是说给定输入输出设备,服务器跑个Linux,无论是用libuv(C)、libevent(C)、netty.io(Java)、asio(C++)、Erlang、Scala等等随便什么框架写的应用,处理效率只可能在某个极限戛然而止。当然这里存在许多迷信成分,就是比如优化内存分配,优化连接,最后都会落实成部署更多的节点。当今C和C++语言连带框架构造的网络服务系统,是当今现有计算机体系网络性能的极限,比如Netflix。你堆什么框架,都是一样,不可能解决根本延迟问题,改进的只是开发的时间、风格、成本问题等等其他方面。
 
顺便提个GPU。这NVIDIA本来就是靠卖硬件吃饭的公司,出货量就是一切。对于应用程序来说,如何驱动GPU工作,那得再加一层驱动核心,上层怎么CUDA或OpenCL,最后都绕不过Driver那个地方。而且Driver还不是问题,Driver本身的职责是个复杂的调用,包括DMA和设备管理了。前者会连到坑爹的IO部分,后者各自厂商有各自的应用解释层,本质上也是用一套API操作GPU。所以对于低延迟和高IO访问、随机访问的程序,GPU是很少干的过CPU。唯一的可能就是当单个步骤的线性计算量很大,CPU不划算的时候,GPU才有用武之地。看,如果GPU性能真的有纸上那么强,现有的游戏帧速度应该早就突破成千上万,GPU计算延迟应该极地,但是其实最后并没有,因为指标和执行是两个概念,参考定理2。可能有人会说AI\ML加速,看,如果真的GPU是终极解决方案,那Google就没有必要发展TPU了,因为无论如何,GPGPU的架构和执行模型不可能干的过独立的芯片。
 
还可以提一下FPGA+PC。这个架构目前云端已经有,号称提供低延迟,但是其实并没有解决本质问题。设想,一台装在机房里的云端节点,插上了FPGA加速卡,然后就号称能做什么了,这个就和GPU一样,不好意思还得走PCI-E总线和MMU内存控制器,一般来说还是得有驱动那一层干这个,不然无法驱动FPGA卡进行工作。这个FPGA表现对比GPU是折中,就是说它的硬件循环延迟要低于CPU(看具体型号),远低于GPU,但是吞吐量是不如CPU和GPU的。FPGA的性能很好计算,看FPGA的频率,看吞吐计算量,当然还有处理逻辑。有些计算FPGA非常有优势,比如FFT,当然也有限制,比如一旦牵涉到了浮点计算这个效能会降低。
 
许多文章已经考虑过FPGA和GPU,比如这一篇《GPU vs FPGA Performance Comparison》,列出了FPGA和GPU的优劣势对比图。
 
那么对于如今的AI来说,GPU是足够用的,比如训练视频流数据,无非就是解码后丢给训练框架,这个地方吞吐不会巨大,一般民用的所谓视频AI分析并没有低延迟的需求。譬如1920x1080@30fps,首先摄像头和编码理论上需要最少2*33=66ms,然后是网络传输的时间,假设为15ms,再加上进入主机程序丢给GPU解码,解码器最少需要1-2帧的延迟,然后是训练然后输出,那么假设我们开始训练一个摄像头的数据,从摄像头接收可见光辐射,到人类坐在办公室里看到镜头,已经需要了最少100ms,再考虑一下实际运行环境以及客户端软件编写水平的差异,最好的结果往往是小于200ms。当然这个延迟对于如今的应用来说可用,但是延迟依然是实在是太高了。这种乐高级别的系统做做某些CV应用还是可以的,毕竟人类没见过几个在街头蒙上面具以奥运会百米冲刺的速度飞奔。
 
那么对于特种应用来说,假设给定网络硬件部分、CPU和操作系统,对于简单计算来说,FPGA是会比GPU效能更高的。因为首先哪怕是50Gbps的NIC,对于单个网络应用来说,单个会话数据流也是吃不满的。那么就是变成了,每一个业务循环输入输出真正完成的时间,才是系统的总延迟。上面的关于视频的问题,显然纯粹FPGA编解码是可以达到所谓的实时性能,也就是整个系统最少有2-3帧时间的延迟。我说的是直接摄像头捕获到输出端的显示,不是什么预录制的视频编解码,这种例子一点意义都没有。
 
许多特种应用,需要极低的延迟。这个时候根据考量,如果是距离在允许范围内,一般只考虑电磁传输,比如微波通信在金融系统中的应用。做金融通讯的可以不计成本的怼高技术和硬件,提高几个ms在交易上是可以有巨大优势的。如今华尔街都是应该目标瞄准纳秒级别的通讯延迟了,豪秒已经没什么搞头了——毫秒是A股水平,上海的租用的机房能够提供大概<50ms的延迟,当然套利组合那边不要创造收益率负83%然后跳楼就行。纳秒级别的通讯配上全球原子钟阵列,这个可以一战。
 
现在问题了,立足于ISA和逻辑门电路的这种体系,本质上是面向GPCPU的,也就是譬如x86这种,你的每一个LEA,每一个CALL,对于CPU来说都是高层API,底层流水线那边都得跑一串。解决方案当然是买卡,买FPGA卡来做,把一部分逻辑丢在网卡上做完,进入PC的都是面向高层的应用,比如数据库IO、可视化监控等等,这些都是属于非延迟关键的场合。当然最后的关键是往往买卡也是搞不定的,因为卡的延迟也会出现,最后应用套利组合的现场会受制于当前的硬件架构,这个是最高的极限,不过一般可以接受。
 
末了,我理想中最佳的低延迟方案是,1)传输部分全部是微波或者光纤,2)高度优化的网络连接接口,3)计算部分直接在硬件层次上完成,理想是ASIC,最多用一下FPGA,4)如果需要外部数据,实现一套硬件Cache,而且编码上百分之百的针对硬件的行为进行优化。这么一套组合拳下来,这个特殊系统的低延迟还是很容易办到的。
 
本文谢绝转载。欢迎行业公司和个人联系探讨。 
posted @ 2019-01-12 11:34 Bo Schwarzstein 阅读(...) 评论(...) 编辑 收藏