GNU bug report logs - #17505
Interface inconsistency, use of intelligent defaults.

Previous Next

Package: coreutils;

Reported by: Linda Walsh <coreutils <at> tlinx.org>

Date: Fri, 16 May 2014 01:26:02 UTC

Severity: normal

Merged with 22277

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


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

From: Linda Walsh <coreutils <at> tlinx.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 17505 <at> debbugs.gnu.org, P <at> draigBrady.com
Subject: Re: bug#17505: Interface inconsistency, use of intelligent defaults.
Date: Fri, 16 May 2014 17:58:16 -0700
Paul Eggert wrote:
> Pádraig Brady wrote:
>
>> The attached patch changes the output to:
>>
>>    $ dd if=/dev/zero of=/dev/null bs=256M count=2
>>    2+0 records in
>>    2+0 records out
>>    536870912 bytes (512 MiB) copied, 0.152887 s, 3.3 GiB/s
>
> I recall considering this when I added this kind of diagnostic to GNU 
> dd back in 2004, and going with powers-of-1000 abbreviations because 
> secondary storage devices are normally measured that way.  For this 
> reason, I expect many users will prefer powers-of-1000 here.  This is 
> particularly true for transfer rates: it's rare to see "GiB/s" in 
> real-world prose.
>
> So it'd be unwise to make this change.
----
   When users see 512 MB copied, they expect it means 512*1024*1024.

The same goes for the GB/s figure.

If you went with Gb/s -- that's different, as we are more used to seeing 
bits/s, which
is why I could go either way with that.

>
>
> The simplest thing to do is to leave "dd" alone, which is my mild 
> preference.  Alternatively, we could make the proposed behavior 
> optional, with the default being the current behavior.  If we do that, 
> though, the behavior shouldn't be affected by the abbreviation chosen 
> for the block size.  Even if the block size is given in powers-of-1024 
> (which is common, because block sizes are about internal memory units, 
> where powers-of-1024 are typical), the total number of bytes 
> transferred and the transfer rates are more commonly interpreted in 
> the external world, where powers-of-1000 are typical.
----
What external world are you talking about?  Where you talk about MB or 
GB /s outside of the
computer world?  If what you said was true, then people wouldn't have 
responded that 125MB/s
was impossible (in the external world) on a 1Gb ethernet.  Yet that's 
what 'dd' displays.
See 
"http://superuser.com/questions/753597/fastest-way-to-copy-1tb-safely-over-the-wire/753617".

See the comments under the the 2nd answer.  "125MB/s is literally 
impossible with a 1Gbit/s line - there will be overhead..."-(Bob)  and
"Without very significant compression (which is only achievable on 
extremely low entropy data), you're never going to see 125 MB/s in any 
direction on GbE." (allquixotic).

They don't believe 125MB/s is possible even though that's what 'dd' 
stated.  It never occurs to
people, talking about computers and speeds that someone has slipped in 
decimal -- it never happened before disk manufacturers wanted to inflate 
their figures.  By not putting a stop
to the nonsense that MB != 1024*1024 when disk manufacturers muddied the 
waters, it's led
to all sorts of miscommunications.  

The industry leader in computing doesn't use KB to mean 1000B, nor 
M=10^6 ... Microsoft's
disk space and rates both use 1024 based measurements. 

So what external world (who's opinion matters in the computer world) are 
you talking about?








This bug report was last modified 9 years and 147 days ago.

Previous Next


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