anthology-of-the-sota

SOTA-074: Adapt buffer sizes to network conditions

1 min read

Properties4
StatusRejected — names a controller — signal, target, update rule — of which none is stated, and no source here describes one. A measured version would resemble what CheckFreq does for checkpoint intervals (SOTA-054)
Tagsdistributed-optimization
SourceLIT-051 — A Unified Architecture for Accelerating Distributed DNN Training in Heterogeneous GPU/CPU Clusters
Introduced byLIT-051 — A Unified Architecture for Accelerating Distributed DNN Training in Heterogeneous GPU/CPU Clusters

Graph View

Source

Jiang et al. (2020), LIT-051 — https://www.usenix.org/conference/osdi20/presentation/jiang.

The same gap as SOTA-073, one step further

“Adapt buffer sizes to network conditions” names a mechanism nobody in the record has and no source here describes. Adapting implies a controller — a signal, a target, an update rule — and none of the three is stated. Without them it is a wish rather than a practice.

There is a real version of it, and it is worth naming so the restatement has somewhere to go: the fusion-buffer trade in SOTA-048 has an optimum that depends on the fabric, so a system that measures achieved bandwidth during the overlap window and adjusts the bucket size is doing something specific and testable. That is closer to what CheckFreq does for checkpoint intervals (SOTA-054’s source) than to anything in LIT-051.

LIT-051 does not support this. Its contribution is described under SOTA-047.

Standing

Flagged for restatement or retirement, together with SOTA-073, SOTA-049 and SOTA-076 — four of the seven practices in this cluster are in the same position, which is what makes it a cluster-level problem rather than four separate ones.

Backlinks