GNU bug report logs - #75649
dd: report base 1024 for bytes per second

Previous Next

To reply to this bug, email your comments to 75649 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Chris Ely <chris.ely <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: dd: report base 1024 for bytes per second
Date: Sat, 18 Jan 2025 09:17:31 -0500

[Message part 1 (text/plain, inline)]

Hello,

human options would be better if it included base 1024 by default, the code
can turn that bit off where it doesn't want it (the si transfer status
value, should be the only place).

I think the minimal changes would be something like this:

https://github.com/coreutils/coreutils/compare/master...tcely:coreutils:patch-1.patch

From fdf9763a069db4f0c80a84efae1232123f3d44a3 Mon Sep 17 00:00:00 2001
From: tcely
Date: Sat, 18 Jan 2025 08:00:46 -0500
Subject: [PATCH] Turn on human_base_1024 by default

There was only one place not using that bit.
Turn it off once rather than turning on multiple places.
---
 src/dd.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/dd.c b/src/dd.c
index 4e914336b9..b0425e29c4 100644
--- a/src/dd.c
+++ b/src/dd.c
@@ -654,6 +654,7 @@ Options are:\n\
 /* Common options to use when displaying sizes and rates.  */

 enum { human_opts = (human_autoscale | human_round_to_nearest
+                     | human_base_1024 | human_group_digits
                      | human_space_before_unit | human_SI | human_B) };

 /* Ensure input buffer IBUF is allocated.  */
@@ -738,7 +739,7 @@ print_xfer_stats (xtime_t progress_time)
   char hbuf[3][LONGEST_HUMAN_READABLE + sizeof slash_s];
   double delta_s;
   char const *bytes_per_second;
-  char const *si = human_readable (w_bytes, hbuf[0], human_opts, 1, 1);
+  char const *si = human_readable (w_bytes, hbuf[0], human_opts & (~
human_base_1024), 1, 1);
   char const *iec = human_readable (w_bytes, hbuf[1],
                                     human_opts | human_base_1024, 1, 1);

[Message part 2 (text/html, inline)]

Message #8 received at 75649 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Chris Ely <chris.ely <at> gmail.com>, 75649 <at> debbugs.gnu.org
Subject: Re: bug#75649: dd: report base 1024 for bytes per second
Date: Tue, 21 Jan 2025 15:15:01 +0000

On 18/01/2025 14:17, Chris Ely wrote:
> Hello,
> 
> human options would be better if it included base 1024 by default, the code
> can turn that bit off where it doesn't want it (the si transfer status
> value, should be the only place).

I'm not sure about that.
Generally data transfer rates (network, usb, disk, ...) are specified in SI units,
so it would be good to be consistent with those for comparison reasons.

cheers,
Pádraig

Message #11 received at 75649 <at> debbugs.gnu.org (full text, mbox):

From: Chris Ely <chris.ely <at> gmail.com>
To: P <at> draigbrady.com
Cc: 75649 <at> debbugs.gnu.org
Subject: Re: bug#75649: dd: report base 1024 for bytes per second
Date: Tue, 21 Jan 2025 10:59:34 -0500

[Message part 1 (text/plain, inline)]

dd is a file oriented program. Files aren't stored with base 10.

For dd, especially, the default block size is 512 bytes, not 500 bytes. The
most valuable comparison isn't to some network graph you may have showing
base 10 speeds, it's to the written file.

I suppose you could display both speeds, but that line is already long. I'd
much rather not see the base 10 numbers at all without a variable/option
requesting them.

Using base 10 with files is only inviting confusion just like it would be
for memory.

On Tue, Jan 21, 2025, 10:15 Pádraig Brady <P <at> draigbrady.com> wrote:

> On 18/01/2025 14:17, Chris Ely wrote:
> > Hello,
> >
> > human options would be better if it included base 1024 by default, the
> code
> > can turn that bit off where it doesn't want it (the si transfer status
> > value, should be the only place).
>
> I'm not sure about that.
> Generally data transfer rates (network, usb, disk, ...) are specified in
> SI units,
> so it would be good to be consistent with those for comparison reasons.
>
> cheers,
> Pádraig
>

[Message part 2 (text/html, inline)]

Message #14 received at 75649 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Chris Ely <chris.ely <at> gmail.com>
Cc: P <at> draigbrady.com, 75649 <at> debbugs.gnu.org
Subject: Re: bug#75649: dd: report base 1024 for bytes per second
Date: Tue, 21 Jan 2025 09:37:24 -0800

On 2025-01-21 07:59, Chris Ely wrote:
> I'd
> much rather not see the base 10 numbers at all

No matter which of the two numbers we display, people preferring the 
other number will complain. This topic has come up before, multiple 
times, with people commenting at lennnngth. See:

https://bugs.gnu.org/17505
https://bugs.gnu.org/22277

I rarely see transfer rates in anything other than SI units. When 
companies market hardware, for example, they invariably use GB/s rather 
than GiB/s because this makes their transfer rates look higher. So like 
Pádraig I'm dubious about changing the transfer-rate line to use base 
1024 only.

More generally, any such proposed patch shouldn't be just to the code: 
it should explain specifically how the patch would affect dd's behavior, 
and this explanation should include changes to the documentation and the 
NEWS file. As things stand I don't know how the patch addresses the 
motivation of avoiding SI units.

[1]: 
https://www.lifestyleasia.com/hk/entertainment/gaming/nintendo-switch-2-announcement-and-updates-news/

Message #17 received at 75649 <at> debbugs.gnu.org (full text, mbox):

From: Chris Ely <chris.ely <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: P <at> draigbrady.com, 75649 <at> debbugs.gnu.org
Subject: Re: bug#75649: dd: report base 1024 for bytes per second
Date: Tue, 21 Jan 2025 13:33:57 -0500

[Message part 1 (text/plain, inline)]

Thank you for the links to the older bugs.

I'm still of the opinion that introducing base 10 output, in the realm of
files that are always stored in base 2 sized blocks, is a mistake that only
confuses people using dd unnecessarily.

On Tue, Jan 21, 2025, 12:37 Paul Eggert <eggert <at> cs.ucla.edu> wrote:

> On 2025-01-21 07:59, Chris Ely wrote:
> > I'd
> > much rather not see the base 10 numbers at all
>
> No matter which of the two numbers we display, people preferring the
> other number will complain. This topic has come up before, multiple
> times, with people commenting at lennnngth. See:
>
> https://bugs.gnu.org/17505
> https://bugs.gnu.org/22277
>
> I rarely see transfer rates in anything other than SI units. When
> companies market hardware, for example, they invariably use GB/s rather
> than GiB/s because this makes their transfer rates look higher. So like
> Pádraig I'm dubious about changing the transfer-rate line to use base
> 1024 only.
>
> More generally, any such proposed patch shouldn't be just to the code:
> it should explain specifically how the patch would affect dd's behavior,
> and this explanation should include changes to the documentation and the
> NEWS file. As things stand I don't know how the patch addresses the
> motivation of avoiding SI units.
>
> [1]:
>
> https://www.lifestyleasia.com/hk/entertainment/gaming/nintendo-switch-2-announcement-and-updates-news/
>

[Message part 2 (text/html, inline)]

Message #20 received at 75649 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Chris Ely <chris.ely <at> gmail.com>
Cc: 75649 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>, P <at> draigbrady.com
Subject: Re: bug#75649: dd: report base 1024 for bytes per second
Date: Tue, 21 Jan 2025 21:06:52 +0100

On Jan 21 2025, Chris Ely wrote:

> I'm still of the opinion that introducing base 10 output, in the realm of
> files that are always stored in base 2 sized blocks, is a mistake that only
> confuses people using dd unnecessarily.

But the size of files is only rarely a multiple of the block size, so
there is no connection between those metrics.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.