这个问题在网络工程(因为它涉及主机)和服务器故障(因为…我不确定)中都被搁置了。我希望在这里更有意义。
首先,一些背景。高频交易者依赖于非常高速的网络。在2014年,他们已经使用10Gb以太网工作在大约750纳秒的水平上,并且竞争达到更低的延迟,而单个纳秒很重要。
令人惊讶的是:10GbE帧每字节大约需要1 ns。因此,从典型的NIC开始接收帧直到完成并使其可用于其余硬件的那一刻起,最小帧就已经经过了至少64 ns。对于1500字节的帧,已超过1微秒。因此,如果您在开始制作之前等待一个完整的帧,那么您将浪费宝贵的时间。
但这正是我所看到的每个以太网NIC所做的!实际上,即使像DPDK或NetMap这样的绕过内核的框架也可以使用粒度的帧,因此它们永远不会达到小于帧的延迟。
考虑以太网帧中的数据从该帧开始的14个字节开始。如果在接收帧的其余部分时开始处理该数据,则将至少节省50 ns,甚至可能节省20 ns。当您争取单个ns时,这将是一个巨大的优势。
我看到两种可能性:
在完全接收到帧之前,HFT等并未计算处理数据的潜在时间收益。似乎很荒谬:他们使用FPGA来提高速度,却浪费了所有等待时间?他们实际上正在使用一些相当专业的硬件,即使按照DPDK标准因此,我的问题是:他们怎么做到的?有谁知道“面向字节的”以太网NIC,它将在帧到达时使帧中的单个字节可用?如果是这样,这样的NIC将如何工作:例如,它将向用户提供标准输出流吗?也许还有自己的网络堆栈/子系统?
现在,我已经从NE和SF中的问题中收集了一些典型的“那是不可能的/不好的/邪恶的”评论,因此我将在这里抢先回答:
您需要产品推荐。
否。如果有的话,如果有一些产品手册能够解释编程模型或对它们如何获得子帧延迟有所了解,那将很有趣。但是目标是学习如何做到这一点。
另外,我了解硬件建议SE。我不是问那里,因为那不是我想要的。
您在问“为什么没有人这样做”。
否。我说过,关于传统NIC不可能说的等待时间很短,我在问他们如何做到的。我怀疑有两种可能:面向字节的NIC和/或自定义硬件。
可能还有其他事情:例如,它们测量约750 ns的方式实际上是从(传统)NIC使帧可用的那一刻开始的。这将解决我所有的疑问。同样,这将是一个令人惊讶的浪费,因为他们已经在使用FPGA节省纳秒的时间。
您需要在帧末尾的FCS来了解该帧是否有效。
FCS是必需的,但您无需等待。看一下主流CPU数十年来使用的推测性执行和分支预测技术:分支之后的一组指令以推测性方式开始工作,如果不采用分支,则仅丢弃已完成的工作。如果猜测是正确的,这将改善延迟。如果不是这样,那么CPU还是会处于空闲状态。
可以在以太网帧上使用相同的推测性技术:在帧的开头开始对数据进行ASAP处理,并且仅在确认帧正确后才致力于该工作。
特别要注意的是,现代以太网被期望不会发现冲突(到处都是交换机),并且被定义为具有非常低的BER。因此,当您担心纳秒时,如果一帧被证明是无效的,则强制所有帧具有1帧的延迟显然是浪费的。
以太网是基于帧的,而不是基于字节的。如果要访问字节,请使用串行协议,而不要混用以太网。
如果在完全接收帧之前访问帧中的数据是“重击”,那么很抱歉将其破坏给您,但是至少自1989年以来,这种情况一直在通过直通切换进行。实际上,请注意,我描述的技术确实会丢掉不良帧,因此它比切入式交换更干净,后者会转发不良帧。
每个字节获取一个中断将是可怕的。如果进行轮询,则需要使用专用于RX的完整CPU。NUMA延迟将使其成为不可能。
所有这些要点已经由DPDK和类似人员(NetMap?)提出。当然,必须仔细配置系统,以确保使用的是硬件,而不是硬件。通过轮询完全避免了中断。单个3 GHz内核足以进行RX,而不会丢失10GbE的帧。NUMA是一个已知的问题,因此您只需要小心处理即可。
您可以使用更高速度的以太网标准以减少延迟。
是的,例如100GbE比10GbE快。但是,如果您的提供商使用10GbE,并且/或者您的竞争也转向100GbE,那将无济于事。目的是减少给定以太网标准上的延迟。