Writes are faster because completion is defined elsewhere
The planned J750/J770 figures put QD1 average 4KB random write at 10 µs against 65 µs for random read. On the same 3D enterprise TLC, program time is far longer than read time, yet the write is the faster of the two — solely because the two define completion differently. A read cannot post its completion until data has actually been sensed out of the array and decoded. A write only has to land in the power-loss-protected write buffer and have its mapping change journalled, and it returns immediately. The NAND program happens after that; it governs steady-state bandwidth and background pressure and never appears on this latency path. Both figures are product-definition/EVT design targets, carried as regression baselines on the internal JH-E4U-C engineering platform.
Acknowledged data is a debt that must be honoured
Acknowledging early is only permissible if the debt can still be settled after power is lost. Data acknowledged but not yet programmed, together with mapping changes not yet committed, must be written out on the energy held on the board. The constraint runs one way only: available energy determines how much can be honoured, and that determines how large the buffer may be. A bigger buffer improves burst write behaviour, but the volume of data and metadata to flush at the instant of power loss rises with it. The planned 18 W typical, 22 W maximum and 6 W idle envelope is the overall boundary this mechanism has to fit inside alongside foreground performance.
Flush and FUA push acknowledgement back to the medium
The 10 µs figure holds only while the host permits the volatile write cache to operate. When an application issues a Flush, or sets FUA on an individual command, NVMe semantics require the data to reach non-volatile media before completion — and the resulting latency is governed by program time, an entirely different order of magnitude. Database journals, filesystem logs and virtualisation write barriers all lean heavily on these two semantics. Any write-latency evaluation therefore has to state whether the workload carries Flush/FUA; without it two reports are not comparable. What firmware can do is make a Flush wait only on the portion that genuinely needs persisting, rather than draining the entire buffer indiscriminately.
The same 10 µs, different steady states
The J750 and J770 share the same QD1 write latency target; they diverge at depth and at steady state. Planned 4KB random write is 300 KIOPS on the J750 and 600 KIOPS on the J770, with five-year DWPD of 1 and 3 respectively. Once the queue deepens, commands begin queuing ahead of the acknowledgement point, garbage collection contends with host writes for the same channels, and the tail of the latency distribution stretches. A larger endurance budget permits more aggressive foreground-priority scheduling at the cost of higher write amplification; the tighter-endurance model has to schedule conservatively. That is exactly why write latency must be sampled on a near-full drive under sustained write traffic — a 10 µs reading taken on a fresh drive carries no information.