数据的低延迟访问是什么意思?
我实际上对这个术语的定义感到困惑。"LATENCY"
谁能详细说明“延迟”一词。
数据的低延迟访问是什么意思?
我实际上对这个术语的定义感到困惑。"LATENCY"
谁能详细说明“延迟”一词。
经典例子:
装满备份磁带的货车是高延迟、高带宽的。那些备份磁带中有很多信息,但是一辆马车需要很长时间才能到达任何地方。
低延迟网络对于流媒体服务很重要。语音流需要非常低的带宽(电话质量 AFAIR 为 4 kbps),但需要数据包快速到达。即使有足够的带宽,高延迟网络上的语音呼叫也会导致扬声器之间的时间延迟。
延迟很重要的其他应用程序:
LATENCY -
获得响应的时间[us]
BANDWIDTH -
每单位时间 的数据流量[GB
/s
]`LATENCY
数字的神秘化方面非常出色如果不仔细考虑事务生命周期的整个上下文,则可能会混淆术语延迟:重定时| 切换 | 多路复用器/映射 | 路由 | EnDec 处理(不谈密码学) | 统计(去)压缩},数据流持续时间和成帧/行代码保护附加组件/(可选协议,如果存在,封装和重新成帧)额外的剩余开销,不断增加latency但也增加了数据VOLUME
- .
举个例子,以任何 GPU 引擎营销为例。关于 GigaBytesDDR5
及其GHz
时序的巨大数字以粗体字表示,他们没有告诉你的是,有这么多东西,你的每一个SIMT
多核,是的,所有核,都必须付费一个残酷的latency惩罚和等待超过s只是从 GPU-over-hyped-GigaHertz-Fast-DDRx-ECC-protected 内存银行接收第一个字节。+400-800
[GPU-clk]
是的,您的超级引擎GFLOPs/TFLOPs
必须等待!...因为(隐藏)LATENCY
而你等待所有完整的并行马戏团......因为LATENCY
(......而且任何营销铃声或口哨都无济于事,信不信由你(忘记缓存承诺,这些不知道,在远/迟/远的记忆单元中到底会有什么,所以不能喂你一个这种延迟的位副本-从他们的浅本地口袋中“远离”谜团))
LATENCY
(和税收)无法避免高度专业HPC
的设计只能帮助支付更少的罚款,但仍然无法避免LATENCY
超出一些智能重新安排原则的(作为税收)罚款。
CUDA Device:0_ has <_compute capability_> == 2.0.
CUDA Device:0_ has [ Tesla M2050] .name
CUDA Device:0_ has [ 14] .multiProcessorCount [ Number of multiprocessors on device ]
CUDA Device:0_ has [ 2817982464] .totalGlobalMem [ __global__ memory available on device in Bytes [B] ]
CUDA Device:0_ has [ 65536] .totalConstMem [ __constant__ memory available on device in Bytes [B] ]
CUDA Device:0_ has [ 1147000] .clockRate [ GPU_CLK frequency in kilohertz [kHz] ]
CUDA Device:0_ has [ 32] .warpSize [ GPU WARP size in threads ]
CUDA Device:0_ has [ 1546000] .memoryClockRate [ GPU_DDR Peak memory clock frequency in kilohertz [kHz] ]
CUDA Device:0_ has [ 384] .memoryBusWidth [ GPU_DDR Global memory bus width in bits [b] ]
CUDA Device:0_ has [ 1024] .maxThreadsPerBlock [ MAX Threads per Block ]
CUDA Device:0_ has [ 32768] .regsPerBlock [ MAX number of 32-bit Registers available per Block ]
CUDA Device:0_ has [ 1536] .maxThreadsPerMultiProcessor [ MAX resident Threads per multiprocessor ]
CUDA Device:0_ has [ 786432] .l2CacheSize
CUDA Device:0_ has [ 49152] .sharedMemPerBlock [ __shared__ memory available per Block in Bytes [B] ]
CUDA Device:0_ has [ 2] .asyncEngineCount [ a number of asynchronous engines ]
POTS
过去基于同步 固定latency
交换的电话服务(70 年代后期已经合并了日本PDH
标准、大陆PDH
运营E3
商间标准和美国运营商之间可以同步的准同步数字体系网络PDH
)T3
服务,最终避免了国际运营商服务抖动/滑点/(重新)同步风暴和辍学带来的许多麻烦)
SDH
/ SONET-STM1 / 4 / 16
,在 155 / 622 / 2488 [Mb/s]
BANDWIDTH
SyncMUX 电路上进行。
很酷的想法SDH
是时间对齐框架的全局强制修复结构,它既确定又稳定。
这允许简单的内存映射(交叉连接开关)低阶容器数据流组件从传入的 STMx 复制到 SDH 交叉连接上的传出 STMx/PDHy 有效载荷(请记住,这与 70 年代后期一样深-ies 所以 CPU 性能和 DRAM 比处理GHz
和唯一的要早几十年ns
)。这种盒内盒内盒内有效负载映射既提供了硬件上的低切换开销,又提供了一些在时域中重新对齐的方法(盒子之间存在一些位间隙-收件箱边界,以提供一些弹性,远低于给定最大时间偏差的标准)
虽然很难用几句话来解释这个概念的美妙之处,但 AT&T 和其他主要的全球运营商非常享受 SDH 同步性以及全球同步 SDH 网络和本地侧 Add-Drop-MUX 映射的美妙之处。
话虽如此,
延迟控制设计
需要注意:
-第一个比特需要多ACCESS-LATENCY :
长时间
-它可以传输/交付每个下一个时间单位的比特数
-总共有多少比特数据运输
-需要多少单位时间
-将整个运输/交付给询问的人: [s]
TRANSPORT-BANDWIDTH :
: [b/s]
VOLUME OF DATA :
: [b]
TRANSPORT DURATION :
___________________ :
VOLUME OF DATA
: [s]
吞吐量(带宽
[GB/s]
)在延迟上的主要独立性的一个很好的说明是在爱立信的一篇关于提高延迟的可爱ArXiv 论文中的图 4中,测试了来自Adapteva[ns]
的多少核 RISC 处理器 Epiphany-64 架构可能有助于降低延迟在信号处理中。理解在核心维度上扩展的图 4,还可以显示可能的场景- 如何通过参与加速/TDMux-ed处理(时间交错)的更多核心来增加BANDWIDTH以及-延迟[GB/s]
[Stage-C]
[ns]
永远不能短于 principalSEQ
-process-durations== [Stage-A]
+[Stage-B]
+的总和,[Stage-C]
与架构允许使用的可用(单/多)核的数量无关。
非常感谢 Andreas Olofsson 和爱立信团队。继续前进,勇敢的人!