Based on the SDxCentral video interview, 9 October 2026. Only the summary sentence published on that page is asserted as fact.
AI Data Path ONTAP Latency 2026-10-20What the interview actually says
SDxCentral published a video interview on 9 October 2026 with Richard Scheffenger of NetApp, filed in the outlet's Cloud & Storage channel and tagged AI and Data. The published summary is a single sentence, and it is the only claim from the source we assert here: “Richard Scheffenger from NetApp explores the complexities of modern data handling, emphasizing latency over bandwidth as the primary challenge.”
The page carries no transcript, so this article attributes no further quote, number, version or product claim to NetApp or to Scheffenger. Everything after this section is our own framing — why that position is technically plausible, and how you would prove or disprove it on your own cluster in an afternoon.
Why "latency over bandwidth" is the right argument for AI data paths
Bandwidth is a throughput property: how many bytes per second move once the pipe is full. Latency is a queueing property: how long a single request waits before it is served. AI pipelines are unusually sensitive to the second, because their access patterns are not the big sequential reads that bandwidth numbers describe.
- Checkpointing. A training job writes state on a timer, then blocks until the write is durable. Wall-clock cost is the acknowledge latency, not the size of the checkpoint.
- Dataset loading. Before each batch the loader does metadata work — lookup, getattr, open — then many small reads. Thousands of dependent round trips, each one a chance to stall a GPU that is already idle.
- Retrieval for inference. A RAG query fans out into many concurrent small reads and returns in the request's own latency budget.
A 100 GB/s array that answers a metadata call in 2 ms will feel slower to a training loop than a 25 GB/s array answering in 200 microseconds, because the loop waits on its slowest step, not on its widest pipe. That is the substance of the framing — and it is why "just add bandwidth" is the wrong first move for an AI workload that is stalling.
Where ONTAP's client-visible latency actually comes from
On the write path ONTAP has a structural advantage: it keeps client-visible latency low by acknowledging writes from NVRAM and batching the disk flushes, so the client's acknowledgement does not wait for the media write to land. Reads have no such shortcut — read latency is cache hits, SSD service time and queue depth. That asymmetry is the whole argument: you can hide write latency with memory, but read latency is a property of how well the working set fits and how deep the queues are.
Protocol choice matters too, because it sets the round-trip floor before any storage work happens — see choosing the right ONTAP protocol for where NFS, SMB, S3, iSCSI, FC and NVMe/TCP each sit.
Measure it before you argue about it
Four ONTAP-native commands separate a data-path problem from a queueing problem:
qos statistics volume latency show
qos statistics volume show
qos statistics workload performance show
system node run -node node1 -command sysstat -M 1 10qos statistics volume latency show splits the wait into read, write and other, which is how you tell whether the client is waiting on the array or on a policy ceiling. sysstat -M shows per-node CPU: a saturated node adds latency that no amount of array bandwidth removes. Reading perfstat output properly is covered in ONTAP performance monitoring.
The guardrail: QoS ceilings create the latency you are measuring
A max-throughput policy group is a queue by design — above the ceiling, I/O waits. If a workload was capped during a capacity incident and the cap was never lifted, the "storage is slow" ticket is really a QoS ticket, and it will show up in the latency split above. Check the ceilings before opening a case: qos policy-group show, then qos workload show -instance. The mechanics of ceilings, floors and adaptive QoS are in the QoS policy groups guide.
What to watch next
The thing to track is whether NetApp follows the interview with published numbers — benchmark results or a technical brief that puts a measured latency curve behind the claim. A video thesis is a position; a latency curve under a real AI workload is evidence. Until that exists, the honest reading is: the argument matches how AI workloads behave, and it is testable on your own cluster with the four commands above.
If you are new to the data path as a whole, the ONTAP learning path puts protocol, performance and QoS in order.
Source: SDxCentral video interview, 9 October 2026. Outcome metric: indexed page plus first impressions on the "NetApp AI data path latency" query cluster in Google Search Console — UNKNOWN until data exists.