当 Training 是瓶颈时,Batch 3的数据在训练时,DataLoading 提前准备了 Batch 7 和 Batch 8 的数据,然后就等着。
当 Preprocessing 是瓶颈时,DataLoading 永远都比 Preprocessing 提前处理了两个 Batch 的数据。
2
什么是流控
Sender 生产数据的速率是 2MB/s,Receiver 消费数据的速率是 1MB/s,数据在网络中传输的速率是 2MB/s。
两个节点各有一个数据缓冲区(Send Buffer/Receive Buffer),大小均为 5MB。
如果 Receive Buffer 是有界的,那么新到达的数据就只能被丢弃掉了。
如果 Receive Buffer 是无界的,那么 Receive Buffer 会持续扩张,最终会导致 Receiver 端内存耗尽。
2
Credit-based Flow Control 的故事
TCP 滑动窗口
上面的动图,演示了 TCP 滑动窗口的工作流程:
假定初始化时,发送 Window 大小为3(后续会随发送情况动态调整),接收 Window 大小为5(固定)。且发送方发送数据包的速率,是接收方消费数据速率的三倍。 Sender 发送 1~3 号数据包,Receiver 接收 1~3 号包,并放置在缓冲区。 接收方消费1号数据包。 接收方回复发送方 Ack=4,即表示发送方接着可以从4号包发送起,Window 大小为3(总大小为5,但是有2个未来得及被消费的数据包);接收方收到该消息后,将滑动窗口移动到4,发送窗口大小为3。 Sender 发送 4~6 号数据包,Receiver 接收 4~6 号包,并放置在缓冲区。 接收方消费2号数据包。 接收方回复发送方 Ack=7,即表示发送方接着可以从7号包发送起,Window 大小为1;接收方收到该消息后,将滑动窗口移动到8,同时将窗口大小调整为1,也就是将发送速率降为了原来的1/3。 Sender 发送 7 号包,Receiver 接收 7 号包。此时接收方的缓冲区已经满了。 假设接收方消费数据出现问题,一直没有消费数据,而此时接收窗口又满了,那么接收方就会回复 ACK=8, Windows 大小为 0。接收方收到该消息后,会讲发送窗口大小调整为 0,即停止发送。 假设接收方恢复了消费数据,那么会重复以上类似 3~5 的过程。
Credit-based Flow Control 概念的提出
关于 Credit-based Flow Control 的激烈论战
Credit-based Flow Control 的直观理解
理论上,Receiver Buffer 永远不会溢出。 流量控制是动态的,可以让 Receiver 一直工作(Keep Receiver Very Busy)。
如果 Credit 丢了怎么办? 传输 Credit 有一定的开销,具体的系统是否能够接受?
Credit-based Flow Control 在其它领域的绽放
PCIe
Intel QPI
RDMA
Flink
3
再回首 OneFlow 的流控设计
没有中心的调度节点。
每个 Actor 都是以异步的方式执行的。
去中心化的设计,轻松解决了超大规模的分布式训练场景下中心调度方式的单点性能瓶颈问题。
异步执行的设计,使流水并行称为可能,理论上,可以最充分地利用硬件资源。