我可以找到 CPU 核心与其缓存、主内存等之间以 ns 或 CPU 周期为单位的延迟。
但似乎很难找到有关现代 GPU 的类似信息。
有谁知道 GPU 的延迟，特别是现代 nvidia GPU（GF110 或更高版本）与其内存之间的延迟，谢谢。
GPU 内存确实具有更大的带宽，但它们的延迟又如何呢？
我听说 GPU 的延迟与 CPU 的延迟一样高，因此基本上使更大的带宽对于许多通用计算任务来说毫无意义，我只需要确认这一点。
是否有关于 AVX2 收集延迟的任何数据？
（例如 _mm256_i32gather_ps 指令访问单个缓存行）
我已经构建了一个树莓派机器人。现在我想从 Raspberry Pi 板载摄像头流式传输视频。我跟着这个教程：http : //blog.miguelgrinberg.com/post/how-to-build-and-run-mjpg-streamer-on-the-raspberry-pi/page/2
所以我终于让它工作了，但现在我想获得尽可能低的延迟。低延迟很重要，因为控制具有这种延迟的机器人是不可能的。
有什么建议吗？祝你今天过得愉快！
我想使用 iPhone 上的加速度计在 iPad 上控制一艘太空船。设备使用 Multipeer Connectivity Framework 连接。我正在使用将两个设备链接在一起的会话对象上的常规 sendData 方法发送加速度计数据。
一切正常，只是有一个非常严重的滞后。然后我开始注意到一些奇怪的事情。消息以突发方式发送，以下是在 iPad 上接收消息之间经过的时间记录。
时间流逝：0.488062
时间流逝：0.002678
时间流逝：0.001255
时间流逝：0.001652
时间流逝：0.005365
经过的时间：0.516167 < - 500ms的间隙
时间流逝：0.004351
时间流逝：0.001268
时间流逝：0.001069
经过的时间：0.001048
这些是来自控制器（iphone）的登录，数据的发送者：
时间流逝：0.099938
时间流逝：0.100045
时间流逝：0.099997
时间流逝：0.099978
时间流逝：0.100027
时间流逝：0.099975
时间流逝：0.099997
时间流逝：0.100296
时间流逝：0.099719
时间流逝：0.099567
经过时间：0.100650
使用每 100 毫秒触发一次的计时器发送数据。(10次/秒)
有了这些信息，我只能假设数据的发送以某种方式缓冲并以另一种速率发送（似乎每 500 毫秒）（2 次/秒）。
我也尝试过使用 NSStream 版本的框架来发送数据。再次注意到同样的爆裂。然后我尝试对 inputStream 进行自己的轮询并消除了突发，但延迟保持不变或更高。感觉大约 500-1000 毫秒。我真的没有测量延迟的正确方法，但是只要尝试控制那艘飞船的体验完全没有价值，我就知道它太高了:)
我很少有做这种编程的经验，所以任何帮助表示赞赏。我什至不知道最终希望延迟多低，但感觉在这样的游戏中，20-50 毫秒的延迟可能是可以接受的。我说的是从 iPhone 到 iPad 的单向延迟。
我想将一些遥测数据从汽车传输到网络应用程序。硬件已经处理好了。它将通过 android 设备每 100 毫秒发送一次数据。
我想知道什么具有更低的延迟，websockets (socket.io) 或 webrtc (Datachannel) ？
谢谢
运行Web应用程序背后HAProxy的1.6.3-1ubuntu0.1，我越来越HAProxy的统计qtime,ctime,rtime,ttime值0,0,0,2704。
从文档（https://www.haproxy.org/download/1.6/doc/management.txt）：
58. qtime [..BS]: the average queue time in ms over the 1024 last requests
59. ctime [..BS]: the average connect time in ms over the 1024 last requests
60. rtime [..BS]: the average response time in ms over the 1024 last requests
(0 for TCP)
61. ttime [..BS]: the average total session time in ms over the 1024 last requests
我期望响应时间在 0-10 毫秒范围内。ttime2704 毫秒似乎高得不切实际。是否有可能单位关闭，这是 2704 微秒而不是 2704 毫秒？
其次，它ttime …
我正在使用 ffmpeg 实现一个（非常）低延迟的视频流 C++ 应用程序。客户端接收到一个使用 x264 的 zerolatency 预设编码的视频，因此不需要缓冲。如上所述这里，如果你使用av_read_frame（）来读取编码视频流的数据包，你将永远有，因为在做的ffmpeg内部缓冲的至少一个帧的延迟。因此，当我在帧 n+1 发送到客户端后调用av_read_frame () 时，该函数将返回帧 n。
通过设置 AVFormatContext 标志 AVFMT_FLAG_NOPARSE 来摆脱这种缓冲 | AVFMT_FLAG_NOFILLIN如在建议源禁用分组解析，并因此中断解码，如在所提到的源。
因此，我正在编写自己的数据包接收器和解析器。首先，这里是使用av_read_frame ()的工作解决方案（包括一帧延迟）的相关步骤：
AVFormatContext *fctx;
AVCodecContext *cctx;
AVPacket *pkt;
AVFrame *frm;
//Initialization of AV structures
//…
//Main Loop
while(true){
//Receive packet
av_read_frame(fctx, pkt);
//Decode:
avcodec_send_packet(cctx, pkt);
avcodec_receive_frame(cctx, frm);
//Display frame
//…
}
下面是我的解决方案，它模仿了av_read_frame ()的行为，尽我所能重现它。我能够跟踪av_read_frame ()的源代码到ff_read_packet ()，但是我找不到AVInputformat.read_packet ()的源代码。
int tcpsocket;
AVCodecContext *cctx;
AVPacket *pkt;
AVFrame *frm;
uint8_t …我想为 AWS 中的托管 Redis 实例启用 redis 延迟监视器。这些是 Redis 延迟监视器的官方详细信息：https : //redis.io/topics/latency-monitor
不幸的是，我latency-monitor-threshold在 AWS 中创建参数组时看不到选择。
我们即将选择 Google Cloud Pub/Sub 作为我们的消息总线。一些消息需要在低延迟持续时间（例如小于 100-200 毫秒）内进行调度。
我在某处读到，在大量消息中，它表现良好，但对于每秒数百条消息等较少数量的消息，Pub/Sub 可能会产生高延迟。
在上一个问题中，主题也不清楚。从 2016 年开始，谷歌云发布/订阅延迟是多少。
是否有任何关于 Pub/Sub 延迟和与消息量关系的定义指标？
我正在尝试在本地模式下为结构化流运行 Apache Spark 字数统计示例，但我得到了 10-30 秒的非常高的延迟。这是我正在使用的代码（取自https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html）：
host = sys.argv[1]
port = int(sys.argv[2])
spark = SparkSession \
.builder \
.appName("StructuredNetworkWordCount") \
.getOrCreate()
spark.sparkContext.setLogLevel("ERROR")
lines = spark \
.readStream \
.format("socket") \
.option("host", host) \
.option("port", port) \
.load()
words = lines.select(
explode(
split(lines.value, " ")
).alias("word")
)
# Generate running word count
wordCounts = words.groupBy("word").count()
query = wordCounts \
.writeStream \
.outputMode("update") \
.format("console") \
.start()
query.awaitTermination()
在编程指南中提到延迟应该在 100 毫秒左右，这似乎不是一个复杂的例子。另一件事要提到的是，当我在没有任何处理的情况下运行它时（只是将数据流式传输到输出），我会立即看到结果。
该示例在 Ubuntu 18.04、Apache Spark 2.4.4 上运行。
这是正常的，还是我在这里做错了什么？
谢谢！加尔