bug#81269: dd (coreutils 9.7): incorrect elapsed time reporting causes impossible throughput (7.9 GB/s)

Paul Eggert <[email protected]> writes:

> On 2026-06-19 00:54, Paul Eggert wrote:
>> from dd's point of view, it asked for the time and got the wrong
>> time from the kernel.
>
> On looking into this a bit more, my guess is that the underlying
> kernel and/or firmware bug is not likely to be fixed any time soon, so
> I installed the attached workaround to coreutils. Please give it a
> try.

I don't think this is the cause. I changed 'dd' to use a monotonic clock
with this commit:

    commit c3eb8b45798133dba06defd72f6280fd1ce3fcd3
    Author:     Collin Funk <[email protected]>
    AuthorDate: Sat Dec 6 17:19:55 2025 -0800
    Commit:     Collin Funk <[email protected]>
    CommitDate: Sun Dec 7 11:37:17 2025 -0800
    
        shred: use gethrxtime instead of time
        
        The gethrxtime function uses a monotonic clock if available on the
        system. The effect should be unnoticeable since we print --verbose
        information every 5 seconds, but is more correct and we already do the
        same in 'dd'.
        
        * src/local.mk (src_shred_LDADD): Add $(GETHRXTIME_LIB).
        * src/shred.c (dopass): Use xtime_t instead of time_t. Use gethrxtime
        instead of time.

The original reporter is using coreutils-9.7, which did not contain this
commit:

    $ git tag --contains=c3eb8b45798133dba06defd72f6280fd1ce3fcd3 \
        | sort --version-sort | head -n 1
    v9.10

Unless a distribution picked up that patch, which I would find
surprising, his version uses gettimeofday.

Collin