时间戳

首页 > 解决方案 > 访问主存的延迟几乎与发送数据包的顺序相同

performance - 访问主存的延迟几乎与发送数据包的顺序相同

问题描述

查看 Jeff Dean 著名的延迟指南

Latency Comparison Numbers (~2012)
----------------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
Disk seek                           10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from disk    20,000,000   ns   20,000 us   20 ms  80x memory, 20X SSD
Send packet CA->Netherlands->CA    150,000,000   ns  150,000 us  150 ms

对我来说有些不可思议的是，从磁盘顺序读取 1MB 所花费的时间仅比跨大西洋发送往返数据包快 10 倍。谁能给我更多的直觉，为什么这感觉是对的。

标签： performancenetworkingdisklow-latency

解决方案

问：1MB SEQ-HDD-READ ~ 比 CA/NL 跨大西洋 RTT 快 10 倍 -为什么感觉不错？

一些“旧”值（从 2017 年开始进行一些跨 QPI/NUMA 更新）从：

           0.5 ns - CPU L1 dCACHE reference
           1   ns - speed-of-light (a photon) travel a 1 ft (30.5cm) distance
           5   ns - CPU L1 iCACHE Branch mispredict
           7   ns - CPU L2  CACHE reference
          71   ns - CPU cross-QPI/NUMA best  case on XEON E5-46*
         100   ns - MUTEX lock/unlock
         100   ns - CPU own DDR MEMORY reference
         135   ns - CPU cross-QPI/NUMA best  case on XEON E7-*
         202   ns - CPU cross-QPI/NUMA worst case on XEON E7-*
         325   ns - CPU cross-QPI/NUMA worst case on XEON E5-46*
      10,000   ns - Compress 1 KB with Zippy PROCESS (+GHz,+SIMD,+multicore tricks)
      20,000   ns - Send 2 KB over 1 Gbps NETWORK
     250,000   ns - Read 1 MB sequentially from MEMORY
     500,000   ns - Round trip within a same DataCenter
  10,000,000   ns - DISK seek
  10,000,000   ns - Read 1 MB sequentially from NETWORK
  30,000,000   ns - Read 1 MB sequentially from DISK
 150,000,000   ns - Send a NETWORK packet CA -> Netherlands
|   |   |   |
|   |   | ns|
|   | us|
| ms|

跨大西洋网络 RTT：

  • 全球光网络大致以光速 ( 300.000.000 m/s)
  • LA(CA)-AMS(NL) 数据包必须通过的不是大地“距离”，而是一组大陆和跨大西洋“海底”电缆，其长度要长得多（见地图）

这些因素并没有 “改善” ——只是传输容量在增长，光放大器、重定时单元和其他 L1-PHY/L2-/L3 网络技术中引入的附加延迟得到控制，尽可能小.

所以 LA(CA)-AMS(NL) RTT 将保持不变，使用这种技术，大约 150 毫秒

使用其他技术，LEO-Sat Cubes——例如——“距离”只会从约 9000 公里 P2P 增加一对额外的 GND/LEO 段，加上一些额外的 LEO/LEO 跃点，这会引入“更长“距离、附加跳/跳再处理延迟和容量不会接近当前可用的光传输，因此不会出现“回到未来”的神奇跳跃（我们仍然怀念 DeLorean）。

硬盘驱动器：

  • HDD-s 可以有非常快速和非常短的传输路径来移动数据，但是READ-ops 必须等待媒体读取头的物理/机械操作（这需要大部分时间，而不是实际数据- 传输到主机 RAM )
  • HDD-s 是旋转设备，磁盘必须“对齐”从哪里开始读取，这首先要花费大约10 [ms]
  • HDD-s 设备将数据存储到磁头的静态结构中（2+，从磁板表面读取物理信号）：圆柱体（板上的同心圆形区域，圆柱对齐的读取头通过磁盘固定在其中头部微控制器）：扇区（圆柱体的角度部分，每个都携带相同大小的数据块〜4KB，8KB，...）

这些因素并没有 “改善” ——所有商品生产的驱动器都保持在行业选择的大约 { 5k4 | 7k2 | 10k | 15k | 18k }-旋转/分钟 (RPM)。这意味着，如果在这样的磁盘上维护一个紧凑的数据布局，一个连续的磁头：柱面对齐读取整个柱面将需要：

>>> [ 1E3 / ( RPM / 60. ) for RPM in ( 5400, 7200, 10000, 15000, 18000 ) ]

11.1 ms per CYL @  5k4 RPM disk,
 8.3 ms per CYL @  7k2 RPM disk,
 6.0 ms per CYL @ 10k  RPM disk,
 4.0 ms per CYL @ 15k  RPM disk,
 3.3 ms per CYL @ 18k  RPM disk.

数据密度也受到磁性介质特性的限制。自旋电子学研发将带来一些更密集存储的数据，但过去 30 年一直处于可靠磁存储的极限之内。

从多个磁头同时并行读取的技巧可以预期更多，但这与嵌入式微控制器的设计背道而驰，因此大部分读取都是按顺序从一个磁头依次进入 HDD - 控制器板载缓冲区，最好不要发生圆柱到圆柱头机械重新对齐（从技术上讲，这取决于先前的数据到磁盘布局，由操作系统维护和磁盘优化器的可能护理（最初称为磁盘磁盘-“压缩”，它只是试图重新对齐已知的FAT描述的数据块序列，以遵循head：cyl：sector转换的最佳轨迹，这主要取决于实际设备的磁头:head 和 cyl:cyl 延迟). 因此，即使是最乐观的数据布局也需要~ 13..21 [ms]寻找和读取，但只有一个 head:cyl-path

物理定律决定

推荐阅读