蛋博士专注小电影十五年，手上的资源没有1000，也有800，而且还在不断增加中。
这么多片子，不好放到网盘上，只能用本地存储，又要考虑备份，容灾，冷热数据分层的问题，少不了要经常拷来拷去。
在多年呼来唤去的拷贝生涯中，蛋蛋永远是SSD市场最早吃螃蟹的1%，PCIe SSD刚出来，蛋蛋立马就用上了：开机以后秒进系统，复制影片飕飕的。
蛋博士跟一般宅男的区别在于，在使用PCIe SSD的同时，还要研究，比如PCIe SSD在PCIe协议层面导致性能损耗的因素：
- Encode & Decode
- TLP Packet Overhead
- Traffic Overhead
- Link Protocol Overhead
- Flow control
- System Parameters
具体研究成果如下：
Encode和Decode：
这个就是我们通常说的8bit/10bit转换（Gen3是128bit/130bit,但是道理一样），这个东西简单来说就是对数据重新编码，从而保证链路上实际传输的时候总体的’1’和’0’比例相当，且不要过多连续的’1’或’0’。
目的是把位发送时钟嵌入跟数据一起发送，避免高频时钟信号产生EMI的问题。
Gen1或者Gen2，正常的1个Byte数据，经过8bit/10bit转换在实际物理链路上传输的时候就变成了10bit,也就是一个Symbol，8bit/10bitbt转换会带来20%的性能损耗。
TLP Packet Overhead:
PCIe SSD通过MemWr或者CplD这两种TLP与主机传输数据，从下图可以看出，整个TLP里Payload是有效的传输data，而PCIe协议在外面穿了一层又一层的衣服。
按照蛋博士的个性，反正这边穿了到那边还要脱，不如裸奔来的自由，但是PCIe没有蛋博士这么奔放，还是必须靠这些东西来保证传输的可靠性。
Transaction Layer: TLP Header, ECRC
Data Link Layer: Sequence, LCRC
PHY Layer: Start, End
这些七七八八的加起来，大概每个TLP会带来20~30 Byte的损耗
Traffic Overhead:
PCIe协议为了进行时钟偏差补偿，会发送Skip Order-set，个人作用有点像SATA的ALIGN（如果有不对请大侠指正）
Gen1/Gen2一个Skip Order-set是4 Byte，Gen3是16 Byte，Skip Order-set是定期发送的，以Gen2为例，每隔1538个 symbol time（symbol time就是PCIe link上发送一个Byte需要花费的时间）就必须发一个。
PCIe协议不允许在TLP中间插入Skip Order-set，只能在两个TLP的间隔中间发，这个也会带来损耗
Link Protocol Overhead：
PCIe跟冬瓜哥一样，是个有态度的协议，RC（主机）和EP（PCIe SSD）之间发送的每一个TLP，都需要对方告知接收的情况。
以主机传输数据给SSD为例：
- 主机发送一个MemRw的TLP以后，会把这个TLP存在自己这边Data Link Layer Replay Buffer里，同时等SSD回复； — 兄弟，货交给你了，你看看
- SSD收到这个TLP以后，如果没问题，就回复ACK – 哥，我知道了，钱你拿好
- 主机收到ACK以后就知道Replay Buffer备份的TLP没用了，可以用后续的TLP覆盖 – 进新货
- SSD收到TLP如果发现有问题，比如说LCRC错误，就回复NAK – 哥，你这货不真啊
- 主机收到NAK以后就把Replay Buffer里的TLP拿出来，再发给SSD一次 — 兄弟，行家啊，哥给你看玩笑呢，你看这个
- SSD再检查，再回复ACK — 双方本次交易完成
像冬瓜哥一样有态度的是要付出代价的，ACK和NAK的发送本身也会造成性能损耗，另外这里还要一个平衡需要掌握：
PCIe要求每一个TLP，都需要对方发送ACK确认，但是允许对方接收几个TLP以后再发一个ACK确认 （收几批货付一次钱），这样可以减少ACK发送的数量，对性能有所帮助。
但是也不能这个连续发送TLP的数量也不能太多，因为Replay buffer是有限的，一旦满了后面的TLP就不能发送了 （资金积压了是没法进新货的）
Flow control：
PCIe跟冬瓜哥一样，是个有腔调的协议，自带一个流控机制，目的是防止接收方 receiver buffer overflow — 作为上家，你不能一直压货，完全不管经销商受不受得了。
RC跟EP之间通过交换一种叫UpdateFC的DLLP来告知对方自己目前receive buffer的情况，显然发送这个也会占用带宽，从而对性能产生影响。
跟ACK类似，UpdateFC的发送需要考虑频繁问题，更低的频繁对性能有好处，但是要求Device有较大的receiver buffer。
System Parameters：
主要有三个，MPS（Max Payload Size），Max Read Request Size和RCB（Read Completion Boundary），前两个专门写过一篇文章介绍，这里简单说一下RCB。
以前看PCIe Trace时候，经常遇到的情况是，PCIe SSD向主机发了一个MemRd的TLP要求数据，虽然MPS是256甚至是512，结果主机回复了一堆的64 Byte或者128 Byte的CplD。
导致这个的原因就是RCB，RC允许使用多个CplD回复一个read request，而这些回复的CplD通常以64 Byte或128Byte为单位（也有32Byte的），原则就是在Memory里做到地址对齐。
研究完这些因素，蛋博士需要量化的计算，这样才知道每次备份小电影的时候需要花多长时间，从而更好的进行小电影业务的时间管理。
蛋博士是个实在人，用的公式浅显易懂： Bandwidth= [（Total Transfer Data Size）/(Transfer Time)] x GB/s
已知条件：
- 200个MemWr TLP
- MPS=128
- PCIe Gen1x8
准备活动：
- 计算Symbol Time，2.5Gb/S换算成1个Byte传输时间是4ns
- 8个lane，所以每4ns可以传输8个Byte
- TLP传输时间：[(128 bytes payload + 20 byte overhead)/8 Byte/clock]* [4ns/clock]=74ns
- DLLP传输时间：[8 bytes/ 8 Byte/clock]* [4ns/clock]= 4ns
假设：
- 每5个TLP回复1个ACK
- 每4个TLP发送一个FC Update
正式计算：
总共的数据： 200×128 Byte= 25,600Byte (25K,蛋博士你在哪找到这么小的电影？)
传输时间：200x74ns+40x4ns+50x4ns=15,160ns
[25,600 Bytes/15,160ns] = 1,689 MB/S
蛋博士看着这个数字，微微皱眉，随手把MPS调整到了512Byte。
重新计算，结果增加到了1912MB/s, 看着这个数字，蛋博士随手把之前的SATA SSD丢进了垃圾桶，又满意的笑了。
以上的例子是以MemWr为例，而MemRd的时候，情况略有不同：
MemWr的TLP是自带Data payload, 而MemRd是先发一个Read Request TLP，而后对方回复CplD进行data传输，而CplD Payload的size则会受到RCB的影响。
放松一下，这篇文章里蛋博士如此青睐的造型，是哪部电影？
