我们已经到了我们希望将软件提升到一个新的水平的阶段，通常响应时间为20μs或更短。 软件方面，它的performance还不错（尽pipe还有一点改进空间），但现在我们正在考虑攻击硬件方面的东西。
我想知道如果你能提供build议，我们如何才能完成这个壮举。 我们是否需要任何特殊types的布线，软件堆栈，架构或其他技术？
超低延迟？ 你可以玩有趣的玩具。 这种低延迟networking通常的平台是InfiniBand （我们几个人，虽然不是我）已经得到使用这个东西了。 用于需要低延迟，高带宽和可扩展性的高性能计算和其他计算领域。 常见于某些科学计算领域。
IB获得低延迟的一部分是通过展开networking。 与光纤通道类似，它是一个二层交换networking，确实有助于降低延迟。
你不会在你的本地MicroCenter上find这个设备。 使用IB进行networking连接是完全可行的，但是如果您想要最低的延迟时间，TCP / IP可能是一个普通的协议select。
由于市场容量较小，与1GB以太网相比，IBnetworking适配器的价格非常昂贵，尽pipe它们与10GbE适配器相比并不逊色。 IB交换机同样价格昂贵，但是与类似端口密度的10GbE交换机似乎接近价格平价。
如果IB让你感到震惊，那么万兆以太网可以帮助你实现这个目标，并且得到了很好的支持，并且对工厂networking爱好者的运行非常熟悉。 如果你devise你的以太网，使其中有一个（也许是2个）交换机，而且所有的端口都在同一个子网中，你可以得到类似的低延迟。 根据您愿意承受多less延迟，这可能是一个比IB更容易理解的架构。
你甚至不知道你打算使用哪种networking技术。
假设以太网并将最小帧长度除以您的20μsRT要求的最小帧长度，则可以使您达到50 MB / s的范围。 进一步假设你的软件至less需要一半的时间进行处理，你的速度是100MB / s，并且在那个时候可能要看10GE，以便能够适应切换和传输延迟。
然后再次，你有足够的空间 – 所以我想知道为什么你打扰类似布线types的东西肯定不会影响你的延迟到数量级，哪里会引人注意。
编辑：我习惯认为解决scheme取决于特定的问题。 虽然10GE延迟和传输特性可能对一个应用程序有好处，但它们可能会给另一个应用程序带来问题。 10 GE，你不能保证RTT，但只是尽力而为的交付。 如果您的networking足够过度devise，那么这可能就足够了，您的应用程序在“大部分时间”内可以在20μs内获得响应。 如果响应时间是一个硬性限制，并且交易将因此而中断，那么您可能需要查看其他（主要是基于单元的）networking技术，例如ATM。
至于Infiniband，如果你想提高效率的话，你可能正在研究一下你的应用程序的RDMAnetworking操作的重要改写。
需要考虑的另一件事是组件之间的距离–10μs仅仅是足够的时间让光线行进1,6 km和返回 – 没有任何组件延迟，也没有考虑位时间。 所以你必须有短距离和短的请求/响应序列才能到达那里。
总而言之，这不是个别组件的问题，而是所选技术的问题。