关注了就能看到更多这么棒的文章哦～

Networking and high-frequency trading

By Jake Edge
November 16, 2022
Netdev
DeepL assisted translation
https://lwn.net/Articles/914992/

高频交易（HFT, high-frequency-trading）行业对自己在做什么以及如何做，总是很注重保密，但 Jump Trading 的 PJ Waskiewicz 来到了 Netdev 0x16 会议，希望能揭开一些神秘面纱，尤其是在 HFT 行业中如何使用网络（networking）。他想把 HFT 的需求与 HFT 之外的传统网络的需求进行一下对比。他还有一些想法来看 Linux 内核可以做些什么从而有助于这些需求，让 HFT 公司可以摆脱目前由行业内多家公司开发和维护的一些定制代码。

Secrets

Waskiewicz 首先指出了这个行业天生的神秘性，这一点有时很有趣，但有时又很令人烦恼，人们对 HFT 知之甚少。例如，在他的公司网站上除了一些办公地点的信息外，几乎没有其他信息；最起码这可能会使招聘工作变得困难。众所周知，HFT 公司会做交易，包括股票（stocks）、期权（options）、证券（securities）等，但 "如何做" 才是最神秘的部分；公司如何决定要执行什么交易，以及如何实际执行？这就是 HFT 公司不想与任何人（尤其是他们在 HFT 领域的竞争对手）分享的秘诀。

他说，维基百科的定义中将 HFT 描述为 "基于算法的交易（algorithmic-based trading）"，也就是以各种方式来分析数据，从而决定是否执行交易。之后这些交易的发生次数会是 "非常非常多"。在准备演讲时，他发现有一项研究中将全球所有交易所的全部交易的 60% 归于 HFT 公司。所有这些交易量都来自于算法决定的交易。

决定交易内容和交易方式的交易策略（trading strategies）都是基于量化分析（quantitative analysis）的。因此，HFT 公司有一群人在查看大量的数据，从数据中提取出一些信号（signal），并利用它来建立模型。这一切的目的都是对未来进行预测，然后利用这些预测来自动执行交易。交易策略的算法可以在软件或硬件中实现。他说，HFT 公司在使用定制硬件来帮助加速这些操作，这已经不是什么秘密了。

HFT 公司存储了大量的数据，团队会用这些来创建模型。过去十年甚至更长时间的市场数据都已经需要 PB 级别的存储空间了。因此非常需要高效地进行数据搬移，但 HFT 网络的首要问题是必须实现可预测的延迟（predictable latency）；Waskiewicz 已经提到，网络抖动（network jitter）会导致 HFT 公司损失惨重，他在演讲中多次提到这个想法。意外的延迟会改变查询和采取行动的时间，从而使得原本计划好的策略不再有效。

HFT 公司（companies）和交易所（exchanges）之间的数据交流受制于交易所，以及其所使用的协议，这里面有各种差异。交易所，如纳斯达克、Eurex 和 KRX，都各自发布了自己的用于进行电子交易（electronic trading）的协议规范（specifications of the protocols）。这些规范中定义了数据包格式、如何查询信息、出入的数据包速率（incoming and outgoing packet rates）等等；每个交易所都有自己的一些细微差别和怪癖。交易所通常在 10Gbps 的标准以太网上运行；据他所知，目前没有向 100Gbps 以太网发展的迹象，尽管有一些关于 25Gbps 的讨论。

在 HFT 公司内部会需要高性能计算（HPC）设备来进行量化分析。他说，这些 HPC 环境需要有大量分布式 CPU 算力和存储的网格网络（grid networks）。在这些内部网络中使用了 Remote RDMA（RDMA），但面临到主要问题仍然是如何达到可预测的延迟。

Latency

他说，如果直接使用内核网络协议栈的话，在延迟方面表现会很差。尽管可以通过一些调整加以改善，比如将 workload 固定在特定的 CPU 上，时刻牢记在 NUMA 中的哪个位置，以及使用在减少 packet jitter 方面比较知名的 interrupt affinity 等技术。CPU isolation 可能就不是那么知名了，不过也是 HFT 业界用来进一步减少 jitter 的手段；CPU 与系统的其他部分隔离开，把 workload 固定钉在这个 CPU 上，从而减少或消除 jitter。

他根据一个简单的 benchmark 中生成了一些图表，从而展示这些技术的效果；这个测试中使用了 netperf 来测量使用了交换机（switch）的 10Gbps 以太网上的 request-response 延迟。正如预期的那样，随着每项技术被加进来，延迟数据无论是最小值还是平均值都变得更好；这些数值都是将该 benchmark 运行 10 次得出的平均值。未经优化的最小值为 51.6µs，平均值为 68.7µs，他说这 "并不算很差"，不过最大延迟是 250-600µs，因此 "有点麻烦"。

然后他展示了在不改变 interrupt-affinity，光把工作固定在指定 CPU 上的结果，这可以看到一个很小的改善（50.1/67.6）。当他再把 interrupt-affinity 加进来从而让 cache 本地性也更好时，就有了更明显的提升（45.4/53.1）；"我们开始要看看减少抖动的这个目标了，这是最重要的目的"。他预计采用 CPU isolation 会让情况变得更好，但意外看到数字变得更差了（47.8/61.1）。他想了想，意识到是 interrupt 带来的干扰，所以他把驱动程序改成了 polling （轮询）模式，关闭中断进行了基准测试。这个结果更符合预期，最小延迟为 41.9µs，平均延迟为 56.3µs。

但这是一个 "一个人造出来非常好控制的测试基准"，他可以根据自己的需要来调整系统和应用程序；这跟使用了传统网络的真实世界完全不一样，也就是还有其他 workload 需要运行，不能像他现在做的那样来静态划分好；但在 HFT 网络环境中，并不需要担心这些。这个环境里就是这种人工控制得很好的测试环境；对于 HFT 环境下的部署来说，其实就是这样的一个 "一切都完美安排好的系统"。

Options

因此，他想知道是否可以使用 express data path（XDP 或通常所说的 AF_XDP）来进行进一步改善。他说："因为我们在任何一个问题上只要用上 eBPF，就可以解决，对吗？"，他的说法获得不少会意的笑声。虽然 XDP 对于 HFT 来说 "还没有用起来"，但他认为在未来可能是一条正确的道路，并对如何达到这一目的有一些想法。

Waskiewicz 说，XDP 允许绕过内核，但实际上并没有绕过内核。这个说法确实很有说服力。他的设想是，对 latency 极其敏感的 "hot path" 数据可以被应用程序识别出来，然后让数据包直接走这条路，而其他数据流量将继续由内核网络协议栈来处理。"在我看来这就像是使用了两个世界中最好的一部分能力。" 有一些需要处理（或解决）的限制因素。比如接收端必须使用 polling 来完成，因为 interrupt 本身就会引入 jitter。据他所知，传输数据还需要进行系统调用，系统调用的上下文切换也会带来 jitter。

他说，CPU isolation 一般都能很好地工作，可是有时候它无法正常使用。他的公司里使用 isolcpus 启动参数来选择要被隔离的 CPU 集合，但仍有一些 "random" 的处理器间中断（IPI）会发生，这 "相当令人烦恼"。在今年的 Linux Plumbers Conference 上，有一个关于 CPU isolation 的 microconference，会上就讨论了他所看到的问题。

在一些环境中，仅仅是使用 SSH 连接到一个 CPU-isolated 的系统，就会引发一连串的事件，最终导致 "TLB[translation lookaside buffer] shootdowns issued to every core on the system"。这些 IPI 导致了 jitter，而且重新填充 TLB 也会导致 jitter。他正试图抽出一些时间来解决这个问题。他遇到的另一个 CPU-isolation 问题是，当有人执行 "cat /proc/cpuinfo" 时，会有一个 IPI 发送给所有处理器；系统这样做是为了获得每个内核的工作频率。对于那些运行着某个经常会检查这些值的 telemetry（监测）程序的系统来说，这尤其是一个问题。他说，在他的公司与红帽公司的合作中，已经在上游 fix 了这个问题。

HPC side

如前所述，跟交易所的连接需要标准以太网，但是内部的 HPC 网格，其中可能有几万到几十万个 CPU，可以（现在也是）使用一些比较奇特的方式。实际上，HFT 中的 HPC 一直是 RDMA 的一个小众市场。量化分析需要在整个网络中移动大量数据并对它们进行并行处理。

在网络的分析方面，也非常关注可预测的延迟（predictable latency），而 RDMA 在这方面表现很好，但他认为有些功能可以表现更好。首先，io_uring 就显示了巨大的前景；它已经从最初作为 libaio 异步 I/O 库的替代物来扩展到可以做很多事情了。Waskiewicz 说，正如 Josh Triplett 在 LPC 上的 io_uring_spawn 演讲所显示的那样，它不再仅仅用于 I/O。很期待能了解是否可以直接将 networking-hardware ring buffer 用做 io_uring 操作的 buffer，从而让数据可以使用利用这个机制来跟硬件交互；这就可以让 HPC 来"更多地使用内核中标准化的东西来取代 RDMA"。

但是，至少现在看来，RDMA 还是 HPC 网络中的统治者；不过他说，每次提到 RDMA 的话，就不得不提到 RDMA over Converged Ethernet（RoCE）。Infiniband 是用在这些 RDMA network 上 fabric，价格昂贵，但这在 HFT 世界里这不是一个问题，因为该行业愿意花钱从而来赚更多的钱。不过，Infiniband 是一种小众技术，这使得很难找到能够管理这个网络并保持其正常运行的技术人才。

RoCE（还有 iWARP）都可以使用以太网设备以及相关的管理技能，但它们也有自己所面临的挑战。融合网络（converged networks）仍然有 jitter 问题，因为它们并不是一个专用的 fabric。这就导致需要额外的设备和配置来减少这种情况。

他说，在之前一天 John Ousterhout 的主题演讲（LWN 分为两个部分报道过）之前，他已经计划要讨论一下 Homa for HPC。Waskiewicz 认为 Homa 的基于远程程序调用（remote-procedure-call，RPC）的方法类似于 RDMA Verbs API。让 Homa 在用户空间和内核中都可用，就能带来更多的灵活性。从维护和成本的角度来看，能够在整个网络中使用标准以太网设备也是很值得的。

他想知道是否有其他的什么选项是 HFT 行业也应该关注的。如果有的话，它们必须能够消除 jitter，正如演讲中多次提到的那样，但它们也必须要实现低延迟。如果延迟是 100µs，那么即使没有任何抖动，也仍然不能用于 HFT，因为 "它相当于每一把都输了"。

Waskiewicz 的演讲没有更多时间了，因此他快速重申了他在演讲中的主要观点。毫不奇怪，jitter 是核心内容；必须确保算法能够获得他们所需要的可预测的延迟，因为 "当算法交易出现混乱时"，交易所本身会受到损害。这种交易造成的问题会很容易触发交易所的断路器（circuit-breakers），或者发生更糟的情况。他很高兴地看到，目前人们正在进行多方面的努力来解决 jitter 问题。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～