问题标签 [low-latency]

这是我想要做的：

我想让用户给我的程序一些声音数据（通过麦克风输入），然后保持 250 毫秒，然后通过扬声器输出回来。

我已经使用 Java Sound API 完成了这项工作。问题是它有点慢。从发出声音到再次从扬声器中听到声音的时间至少需要 1-2 秒，我什至还没有尝试实现延迟逻辑。理论上应该没有延迟，但确实存在。我知道您必须等待声卡填满其缓冲区或其他任何东西，并且样本大小和采样率与此有关。

我的问题是：我应该继续沿着 Java 路径尝试这样做吗？如果可能的话，我想将延迟降低到 100 毫秒。有没有人有使用 Java 的 ASIO 驱动程序的经验？应该是更快了。。

另外，我是一个 .NET 人。这是否与 .NET 相关？C++呢？我正在寻找合适的技术在这里使用，也许是如何使用您建议的技术平台读/写音频输入/输出流的一个很好的例子。谢谢你的帮助！

我正在构建一个应用程序，其中包含一个以或多或少的交互方式批量标记数百万条记录的功能。用户交互与 Gmail 非常相似，用户可以标记单个电子邮件，或批量标记大量电子邮件。我还需要对这些标签成员身份进行快速读取访问，并且读取模式或多或少是随机的。

现在我们正在使用 Mysql 并为每个标签文档对插入一行。将数百万行写入 Mysql 需要一段时间（高 I/O），即使是批量插入和大量优化。我们需要这是一个交互过程，而不是批处理过程。

对于我们存储和读取的数据，数据的一致性和可用性不如性能和可扩展性重要。因此，如果在写入时发生系统故障，我可以处理一些数据丢失。但是，数据肯定需要在某个时候持久化到辅助存储中。

所以，总结一下，要求如下：

• 潜在数千万条记录的低延迟批量写入
• 数据需要以某种方式持久化
• 低延迟随机读取
• 不需要持久写入
• 最终的一致性是好的

以下是我看过的一些解决方案：

• 写在缓存（Terracotta、Gigaspaces、Coherence）后面，记录被写入内存并异步排入数据库。这些让我有点害怕，因为它们似乎给我想要避免的应用程序增加了一定的复杂性。
• 高度可扩展的键值存储，如 MongoDB、HBase、Tokyo Tyrant

阅读一些关于低延迟计算的精彩演讲。他们参考了 IBM 的 XL C/C++ 编译器数据缓存操作__dcbt（Data Cache Block Touch），用于他们的单元编译器。该操作将一块内存加载到 L1 缓存中。

Visual Studio（或 G++ 或 Intel）是否具有适用于 Intel 处理器的类似功能？如果是这样并且解决方案是特定于平台的（即仅限 Windows 或 *nix），请这样说。

我正在做一个互联网游戏项目，该项目涉及在两台普通家用 PC 之间通过互联网发送小规模数据（1K 到 50K 之间）。我关心的关键是延迟。

我知道 TCP，UDP 是流行的。TCP 可靠但比 UDP 慢，而 UDP 不安全，我必须实现自己的故障处理代码。

我只是想知道我可以遵循任何其他协议在两台普通家用 PC 之间发送/接收小数据吗？

就普通家用电脑而言，我假设它们具有普通宽带（512kbps - 2Mkbps）和世界各地（可能在美国和日本之间）。

另一个大问题是：

如果我从一台电脑（在英国）ping 到另一台电脑（在日本），我会得到 300 毫秒的延迟。是否可以找到一种协议或使用 TCP/UDP 发送/接收低于 300 毫秒延迟的 1KB 数据？或 ping 应该是了解两个端点之间最低延迟的最快方法？

谢谢

我想为 Java 低延迟应用程序创建全面的清单。你能在这里添加你的清单吗？

这是我的清单
1. 使您的对象不可变
2. 尝试减少同步方法
3. 锁定顺序应该有据可查，并小心处理
4. 使用分析器
5. 使用 Amdhal 定律，并找到顺序执行路径
6. 使用 Java 5并发实用程序和锁
7. 避免线程优先级，因为它们依赖于平台
8. 可以使用 JVM 预热
9. 更喜欢不公平的锁定策略
10. 避免上下文切换（许多线程会导致适得其反）
11. 避免装箱、拆箱
12. 注意编译器警告
13. 线程数应等于或小于内核数

低延迟应用程序每毫秒调整一次。

我正在设计一个应用程序，它有一个网络接口，用于提供大量非常小的元数据请求。应用程序代码本身非常快，基本上是查找缓存在内存中的数据并将其发送给客户端。

对于在 linux 机器上运行的网络应用程序服务器，我可以获得的绝对最低延迟是多少？这将是一个在 gigE 上运行的内部应用程序，无需身份验证。考虑的任何语言/框架，优先考虑 C、C++ 或 Python。协议也是如此，尽管 HTTP 会很好。

这只是与我一直想知道的一些高性能计算有关的一般问题。某个低延迟消息传递供应商在其支持文档中谈到使用原始套接字将数据直接从网络设备传输到用户应用程序，并且这样做它谈到了比它更进一步减少消息传递延迟（在其他公认的深思熟虑的设计决策）。

因此，我的问题是针对那些在 Unix 或类 Unix 系统上了解网络堆栈的人。使用这种方法，他们可能实现多少差异？随意回答记忆副本、获救的鲸鱼数量或威尔士大小的区域；）

据我了解，他们的消息传递是基于 UDP 的，因此建立 TCP 连接等没有问题。对此主题的任何其他兴趣点将不胜感激！

最良好的祝愿，

麦克风

在 linux 2.6 中发送/接收 TCP/UDP 数据包的过程中延迟的来源是什么？

我想知道“乒乓”延迟测试中的延迟源。

有一些关于以太网延迟的相当不错的论文，但它们仅涵盖了线路和交换机中的延迟源（并且相当粗略，仅针对特定交换机）。

数据包之后有哪些处理步骤？

对常用 ping (icmp) 进行深度延迟分析的论文也会很有用。

我依赖社区:)

我需要在两台机器之间以尽可能低的延迟定期发送（交换）大量数据。网络相当快（例如 1Gbit 甚至 2G+）。操作系统是linux。使用 1 个 tcp 套接字（用于发送和接收）还是使用 2 个单向 tcp 套接字会更快吗？

此任务的测试非常类似于 NetPIPE 网络基准测试 - 测量从 2^1 到 2^13 字节大小的延迟和带宽，每个大小发送和接收至少 3 次（在青色任务中，发送次数更多。两者进程将发送和接收，就像乒乓球一样）。

2个单向连接的好处来自linux：

http://lxr.linux.no/linux+v2.6.18/net/ipv4/tcp_input.c#L3847

禁用快速路径的所有其他条件都是错误的。并且只有非单向套接字会阻止内核从快速路径接收

我一直在研究各种第三方库和 .Net 中低延迟串行通信的方法。我已经读了足够多的书，现在我已经完成了一个完整的循环，并且由于各种相互矛盾的意见，我知道的和刚开始时一样少。

例如，框架中的功能被排除在外，因为一些令人信服的文章指出：“微软提供的解决方案在框架版本之间并不稳定，并且缺乏功能。”

我发现有文章抨击了许多旧的基于 COM 的库。由于垃圾收集，我发现有文章抨击整个低延迟 .Net 应用程序的想法。

我还阅读了一些文章，这些文章展示了出于低延迟通信目的的 P/Invoking Windows API 功能是不可接受的。

这排除了我能想到的任何方法！

我真的很感激那些去过那里/做过那种经历的人的话。理想情况下，我可以找到一个可靠的库/合作伙伴，而不必自己构建通信库。我有以下简单的目标：

• C#/VB.Net 中的持续低延迟串行通信
• 32/64 位
• 有据可查（如果解决方案是第 3 方）
• 垃圾收集相对不受影响（通信和延迟方面）。
• 灵活（我不知道将来要与什么接口！）我唯一确定的要求是我需要能够与许多不同的工业设备接口，例如基于 RS485 的线性执行器、串行/微控制器基于仪表和 ModBus（也是 RS485）设备。

非常感谢任何可能消除我的困惑的评论、想法、想法或文章链接！