第一次在国内航班体验机上WiFi

于2023年8月3日乘坐了厦门航空的MF8208从西安飞往厦门,执飞飞机是一架BOEING 787-8宽体型客机,上飞机后惊奇地发现座位旁有WiFi图标,而在地面上我拿手机搜索了一圈并没有看到任何非个人热点的SSID。但我依然非常期待,因为距离上一次在空中上网已经是2013年在美国使用gogoinflight了。 初见WiFi 升空后没多久,我再次刷新手机的WiFi列表,果然出现了XiamenAir,连上WiFi第一步那自然是购买然后连接,但很遗憾的是刚开始并无法完成购买,http portal页面显示“获取用户IP地址失败”。 既然想付钱都不给我付钱的渠道,那我只能试试看能不能用点白嫖手段了。发现可以使用UDP 53进行DNS查询,包括TXT记录查询,同时对公网的任意域名请求均正常,但使用53端口跑别的应用全部连不到服务器,继续测试发现我使用任意域名进行DNS查询都会返回相同的结果,且第二次换一个DNS服务器查询非常快,因此可以判定它对53端口进行了本地重定向,至此我能想到的有实用价值的白嫖网络手段全部失效(我不考虑基于txt记录做的递归查询dns tunnel,对dns缓存的负载太致命了,除非真的到了有紧急情况发生我想传个遗书到地面我才会考虑这种手段吧)。 后来,等进入了平飞阶段,客舱服务开始,此时我也拿出笔记本,在登录页面点击购买后,立刻就收到了几条微信信息,看来我朋友说的不认证能用微信是真的,我果断再次测试,portal页面里可以购买wifi服务了,只不过他们似乎做的不是很好,PC端的购买需要在手机使用微信小程序完成,但问题不大。 其中,这里的付费上网服务也可以使用积分兑换,“一鹭畅游”服务需要2800积分,我当时过于激动没有check一下我的积分是否足够就直接付了钱,后来发现是够的。 未认证阶段的HTTP互联网访问 可以看出这个CSS应该是基于的深信服的系统。 路由与延迟测试 首先是出口ip测试 cyy@YangyuMacBook-Pro  ~ …

尝试Xilinx FPGA上的BUFGCE

最近在学习Firesim,其中对我自己科研很重要的一个功能便是FASED提供了Memory Timing Model的模拟。因为之前和别人合作论文曾被审稿人提出过100MHz FPGA使用1600MHz的内存,使得内存的延迟非常低,其性能表现像是一个大的LLC Cache而不是真实的内存,导致访存性能与真实ASIC上实际使用存在差异,但对于我目前的某个科研项目来说,真实的访存性能非常重要,为了防止重蹈覆辙,决定学习一些先进仿真技术。 然而我们不难想到,模拟一个真实的Memmory Timing Model离不开整个RTL的暂停,这一功能对于Firesim实现在其MIDAS(Golden Gate)中,在FPGA物理上我们考虑两种做法: 关掉寄存器的CE 使用Clock Gating的方式关闭时钟,使其部分停止运行 其中,不难想到1会导致非常多的fanout问题(一般FPGA对Clock的fanout有特殊处理,和逻辑资源不同),而2则是在ASIC中节能的一种方式,也是最为常见的RTL暂停方法,同样MIDAS也是这么使用的。由于我过去没有自己写过BUFGCE,因此很好奇其具体Implementation的样子,因此做了一个尝试。 首先写了一个简单的counter模块: module counter( input clock,…

浅谈早期 Fault Tolerance 虚拟机原理

背景 最近遇到了一些灵车硬件损坏问题,包括自己的台式机 13900K CPU 突然死机后重启就出现 CPU soft lockup,再重启直接无法点亮;自己的旧台式机出现 Correctable ECC 报错(感谢AMD消费级CPU也部分支持ECC);以及一台别人的服务器上解压tar.gz包出现了CRC错误。一周内的这些经历使我开始思考云计算场景如何Tolerance这些奇怪的硬件损坏问题,于是看到了一篇VMWare vSphere 4(2010)年代的论文——The Design of a Practical System…

DDR4与HBM在UltraScale+ HBM上的IOPS测试

最近一个科研idea需要measure一些内存器件的latency数据,因此用FPGA对主流的内存器件的访问Latency进行了一个调研,诚然这样的结果和FPGA上具体Memory Controller的IP实现有关,但也可以作为一个参考,相信Xilinx的实现。 实验基于浪潮F37X FPGA卡,FPGA采用与VCU128相同的vu37p,属于Xilinx Ultrascale+ HBM系列,具体型号也与VCU128完全相同,这个卡其实设计和U280非常类似,但是比U280多了一个通道的DDR4也多了8GB存储容量,个人觉得还是一个比较不错的卡(但可惜不好买,我在闲鱼上买还遇到了奸商,买两张确认收货后发现有一张卡综合后的bit流如果有逻辑分布在指定bank就会有问题,结果卖家不懂FPGA也不认,巨大亏损)。 vu37p本身有2个4GB的HBM,Xilinx官方介绍其拥有460GB/s的bandwidth,我使用的这张FPGA卡也拥有3通道的72bit DDR4 2400 8GB内存(额外8bit用于ECC),一共24GB容量。 测试代码 为了做这个测试,我自己写了一个名为axi_iops的小项目,位于github.com:cyyself/axi_iops.git ,纯Verilog大概200行,用于对AXI随机读性能进行测试。该测试会使用LFSR随机生成一个地址,然后按照用户给定的arlen,arsize去发送请求。 在这个代码中,我们重点关注以下几个IO: module axi_iops #( parameter…

让Thunderbolt可以使用更大的BAR

问题描述 在Xilinx 7-Series FPGA上用AXI Memory Mapped to PCI Express IP核设置了一个256M的BAR,这个BAR直接连接到主板的PCIe上可以正常进行MMIO,但将FPGA通过Thunderbolt硬盘盒+M.2转PCIe连接到Thunderbolt上却无法使用。 通过查阅dmesg可观测到如下报错信息: [ 246.677146] pci 0000:0c:00.0: BAR 0: no…

Augury: Using Data Memory-Dependent Prefetchers to Leak Data at Rest 阅读笔记

概述 这是一篇发表在Oakland’22 (aka IEEE S&P) 的文章,讲的是在Apple M1上发现了前所未有的Data Memory-Dependent Prefetcher(下称DMP),该预取器也带来了前所未有的侧信道攻击。作者对DMP以及可能的攻击进行了介绍,并在M1上进行了相关实验,展示了M1上DMP的运行条件,预取的范围等,并对如何缓解进行了展示。 什么是DMP 作者先用一张图阐明了传统预取器与DMP的区别。传统预取器只考虑地址以及后续地址的关联来进行预测,对预取到的data并不care,这就使得一些场景,例如 pointer-chasing 并不能很好地处理。而DMP在进行预测时也将过去取到的data纳入考虑,这就可以通过一定的方式对data中的指针进行识别。 对于DMP而言,一个十分有用的场景可以是访问一个array of pointers,预取器可以从这个array中得到要预取的地址,从而先预取,而不必等待CPU流水线拿到指针所指的地址后,再一步步把地址发给LSU再发给Cache,从而大幅加快这种情况的访问速度。 而作者提到,尽管过去已经相关工作指出DMP潜在的侧信道,但在Apple M1之前,没有商业级处理器实现这个功能,作者测试了当时所有的Intel和AMD的处理器,均无发现这种加速的现象。…

sPIN: High-performance streaming Processing in the Network 阅读笔记

这是一篇来自SCPL@ETHZ组在SC’17上的一篇文章。主要想法是在RDMA网卡上加入一个处理器用来Offloading一部分数据移动任务,并在LogGOPSim与gem5上进行了实验。 原文链接 Motivation 当前高能效处理器组成的高度可扩展的系统发展带来了总线互联的压力。例如在400Gbps的网络中,一个64B的数据包的传输时间只有1.2ns(不考虑帧间距),而即使有了RDMA解决了频繁的CPU中断让网卡直接访问内存也造成了一些瓶颈。例如RDMA将数据接收到一段内存的缓冲区,然后CPU上的应用读取来完成处理,然后写回一段发送缓冲区再发送到网络上,在上下文切换与内存带宽以及内存延迟层面都带来了巨大的Overhead。 这里引用一张作者Talk中的图: 为了解决这个问题,作者提出了sPIN(SC’17),其实就是在网卡上加了数个小处理器来专门处理数据移动的问题,后续sPIN还提出了RISC-V核实现叫做PsPIN(ISCA’21)。 Design 大致架构图如下,其工作主要是给网卡加入了HPU(handler processing units): 其中,收到的数据包首先存储到Fast shared memory中,被Scheduler分发到HPU上进行处理,在必要时才通过DMA访问Host主存。 此外,文中还有个小细节提到,HPU可以实现为GPU类似的硬件上下文架构,原文如下: HPUs can be implemented…

Draco(MICRO’20) Architectural and Operating System Support for System Call Security 阅读笔记

要解决的问题 Linux内核提供了seccomp来对syscall权限进行检查,被广泛应用在容器、沙盒等多种场景,例如Docker和Android。但原版seccomp的实现是通过BPF对定义的规则一条条进行检查,如下图所示,十分低效: 同时,作者也进行了一系列的benchmark发现这样的检查带来了较大的开销: 其中,左边的docker-default指的是Docker默认使用的seccomp-profile,syscall-noargs指的是使application-specific profile但只检查syscall id而不检查参数,而syscall-complete就在noargs的基础上加上参数检查,最后加上-2x的后缀表示的是这些检查复制2次,来建模更复杂的安全检查场景。 可以看出,seccomp检查带来的开销即使是对于像nginx这样的macro-benchmarks也是比较大的,但现有的seccomp使用BPF,规则十分灵活,因此需要针对这种灵活的规则设计一种加速的方法。 Observation 检查系统调用ID会给Docker容器中的应用带来明显(noticeable)的性能开销。 检查系统调用参数比只检查系统调用ID的开销大得多(significantly more expensive)。 规则加倍,开销加倍。 syscall with 相同id和参数存在局部性(下图指明了实验中的距离) 解决方法 为了解决这个问题,作者引入了一个Fast…