Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #227649 > unrolled thread

Question: SSD speed

Back to article view | Back to linux.debian.user

Contents

  Question: SSD speed Hans <hans.ullrich@loop.de> - 2020-10-07 10:50 +0200
    Re: Question: SSD speed Georgi Naplatanov <gosho@oles.biz> - 2020-10-07 11:40 +0200
    Re: Question: SSD speed Steve McIntyre <steve@einval.com> - 2020-10-07 12:00 +0200
    Re: Question: SSD speed "Jeremy Nicoll" <jn.ml.dbn.25@letterboxes.org> - 2020-10-07 12:00 +0200
      Re: Question: SSD speed Sven Hartge <sven@svenhartge.de> - 2020-10-07 12:50 +0200
        Re: Question: SSD speed Michael Stone <mstone@debian.org> - 2020-10-07 15:10 +0200
          Re: Question: SSD speed Andrei POPESCU <andreimpopescu@gmail.com> - 2020-10-08 11:00 +0200
            Re: Question: SSD speed "Thomas Schmitt" <scdbackup@gmx.net> - 2020-10-08 12:00 +0200
              [SOLVED] Re: Question: SSD speed Hans <hans.ullrich@loop.de> - 2020-10-08 12:20 +0200
              Re: Question: SSD speed Michael Stone <mstone@debian.org> - 2020-10-08 15:20 +0200
                Re: Question: SSD speed "Thomas Schmitt" <scdbackup@gmx.net> - 2020-10-08 16:00 +0200
                  Re: Question: SSD speed Michael Stone <mstone@debian.org> - 2020-10-08 16:20 +0200
                    Re: Question: SSD speed Stefan Monnier <monnier@iro.umontreal.ca> - 2020-10-08 17:40 +0200
                      Re: Question: SSD speed Michael Stone <mstone@debian.org> - 2020-10-08 17:50 +0200
                        Re: Question: SSD speed Stefan Monnier <monnier@iro.umontreal.ca> - 2020-10-08 18:00 +0200
                Re: Question: SSD speed Leslie Rhorer <lesrhorer@att.net> - 2020-10-08 20:30 +0200
                  Re: Question: SSD speed Dan Ritter <dsr@randomstring.org> - 2020-10-08 20:40 +0200
                  Re: Question: SSD speed Michael Stone <mstone@debian.org> - 2020-10-08 21:20 +0200
                    Re: Question: SSD speed Leslie Rhorer <lesrhorer@att.net> - 2020-10-09 02:00 +0200
                      Re: Question: SSD speed Michael Stone <mstone@debian.org> - 2020-10-09 02:20 +0200
                        Re: Question: SSD speed Leslie Rhorer <lesrhorer@att.net> - 2020-10-09 02:40 +0200
                  Re: Question: SSD speed Stefan Monnier <monnier@iro.umontreal.ca> - 2020-10-09 00:20 +0200
                    Re: Question: SSD speed Leslie Rhorer <lesrhorer@att.net> - 2020-10-09 02:20 +0200
                      Re: Question: SSD speed Stefan Monnier <monnier@iro.umontreal.ca> - 2020-10-09 15:50 +0200
      Re: Question: SSD speed Alberto Sentieri <22t@tripolho.com> - 2020-10-07 13:30 +0200
        Re: Question: SSD speed "Jeremy Nicoll" <jn.ml.dbn.25@letterboxes.org> - 2020-10-07 14:50 +0200
          Re: Question: SSD speed Andrei POPESCU <andreimpopescu@gmail.com> - 2020-10-08 10:50 +0200
      Re: Question: SSD speed Hans <hans.ullrich@loop.de> - 2020-10-07 18:50 +0200
        Re: Question: SSD speed "Jeremy Nicoll" <jn.ml.dbn.25@letterboxes.org> - 2020-10-07 18:50 +0200
        Re: Question: SSD speed Andy Smith <andy@strugglers.net> - 2020-10-07 19:50 +0200
          [SOLVED] Re: Question: SSD speed Hans <hans.ullrich@loop.de> - 2020-10-07 20:00 +0200
          [SOLVED] Re: Question: SSD speed Hans <hans.ullrich@loop.de> - 2020-10-08 09:10 +0200
    Re: Question: SSD speed Andrei POPESCU <andreimpopescu@gmail.com> - 2020-10-08 11:00 +0200

Page 1 of 2  [1] 2  Next page →

#227649 — Question: SSD speed

Hi folks, 

I have a little question. Smartctl is telling me, that my ssd drive is 6Gb/sec 
capable, but the actual speed is only 1,5GB/sec.

The notebook is a little bit older, AMD CPU with 2x2,4 GHz, 4GB RAM, debian/
testing.

My question is now: How is the speed of the ssd set? Is it set by the hardware 
or is it set during loading the kernel module?

And is there a possibility to set the speed to 6Gb/sec , i.e. by setting some 
parameters or by loading the kernel modules with additional tags?

I searched the web, but found no other information than "use trimming" (which 
does the kernel during installation automatically, and this system is 
correctly trimmed).

It would be nice, if someone knows more. Strangely, my netbook got 3Gb/sec, my 
Notebook only 1,5 Gb/sec, so I have the idea, it might be a configuration 
thing.

Thanks for any help!

Best regards

Hans

[toc] | [next] | [standalone]

#227650

Hi Hans,

6Gb/s is the maximum speed of SATA controller. Each SSD has its own
speed. For example maximum speed for SATA SSDs from Samsung is about
500MB/s what is about (8*500MB/s) 4Gb/s.

HTH

Kind regards
Georgi

On 10/7/20 11:39 AM, Hans wrote:
> Hi folks, 
> 
> I have a little question. Smartctl is telling me, that my ssd drive is 6Gb/sec 
> capable, but the actual speed is only 1,5GB/sec.
> 
> The notebook is a little bit older, AMD CPU with 2x2,4 GHz, 4GB RAM, debian/
> testing.
> 
> My question is now: How is the speed of the ssd set? Is it set by the hardware 
> or is it set during loading the kernel module?
> 
> And is there a possibility to set the speed to 6Gb/sec , i.e. by setting some 
> parameters or by loading the kernel modules with additional tags?
> 
> I searched the web, but found no other information than "use trimming" (which 
> does the kernel during installation automatically, and this system is 
> correctly trimmed).
> 
> It would be nice, if someone knows more. Strangely, my netbook got 3Gb/sec, my 
> Notebook only 1,5 Gb/sec, so I have the idea, it might be a configuration 
> thing.
> 
> Thanks for any help!
> 
> Best regards
> 
> Hans
> 
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#227651

Hans wrote:
>
>I have a little question. Smartctl is telling me, that my ssd drive is 6Gb/sec 
>capable, but the actual speed is only 1,5GB/sec.
>
>The notebook is a little bit older, AMD CPU with 2x2,4 GHz, 4GB RAM, debian/
>testing.
>
>My question is now: How is the speed of the ssd set? Is it set by the hardware 
>or is it set during loading the kernel module?
>
>And is there a possibility to set the speed to 6Gb/sec , i.e. by setting some 
>parameters or by loading the kernel modules with additional tags?
>
>I searched the web, but found no other information than "use trimming" (which 
>does the kernel during installation automatically, and this system is 
>correctly trimmed).
>
>It would be nice, if someone knows more. Strangely, my netbook got 3Gb/sec, my 
>Notebook only 1,5 Gb/sec, so I have the idea, it might be a configuration 
>thing.

You're seeing the different transport speeds of different SATA
versions. SATA 1 does up to 1.5Gb/sec, SATA 2 does up to 3 GB/sec,
SATA 3 -> 6 GB/sec. The drive will be reporting that it's capable of
SATA 3 (hence the 6GB/sec number), but it will fall back to older
modes as needed for compatibility with the controllers in your
computers.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"You can't barbecue lettuce!" -- Ellie Crane

[toc] | [prev] | [next] | [standalone]

#227652

On Wed, 7 Oct 2020, at 09:39, Hans wrote:
> Hi folks, 
> 
> I have a little question. Smartctl is telling me, that my ssd drive is 6Gb/sec 
> capable, but the actual speed is only 1,5GB/sec.

If your SATA (presumably) connection from the machine to the SSD is a 
6 Gbps one, the maximum data transfer speed in bytes across that
connection would be one eighth of that (as there's 8 bits per byte), so 
about 760 MBps.

That's about half of your "1,5GBps".  That makes me wonder if your 
SSD uses two SATA channels at once - is that even possible?

Alternatively, do any SSDs compress data before sending it across the
SATA channel?

-- 
Jeremy Nicoll - my opinions are my own.

[toc] | [prev] | [next] | [standalone]

#227653

Jeremy Nicoll <jn.ml.dbn.25@letterboxes.org> wrote:
> On Wed, 7 Oct 2020, at 09:39, Hans wrote:

>> I have a little question. Smartctl is telling me, that my ssd drive
>> is 6Gb/sec capable, but the actual speed is only 1,5GB/sec.

> If your SATA (presumably) connection from the machine to the SSD is a
> 6 Gbps one, the maximum data transfer speed in bytes across that
> connection would be one eighth of that (as there's 8 bits per byte),
> so about 760 MBps.

> That's about half of your "1,5GBps".  That makes me wonder if your SSD
> uses two SATA channels at once - is that even possible?

Only with SAS drives. And usually only for redudancy and not for
concurrency.

I question the benchmark Hans did.

Something tells me he either used "hdparm -tT", which is known to
misrepresent the speeds on modern drives, or wrote too little data so he
was benchmarking the Kernel cache and not the drive.

S!

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#227656

On Wed, Oct 07, 2020 at 12:48:09PM +0200, Sven Hartge wrote:
>Jeremy Nicoll <jn.ml.dbn.25@letterboxes.org> wrote:
>> On Wed, 7 Oct 2020, at 09:39, Hans wrote:
>
>>> I have a little question. Smartctl is telling me, that my ssd drive
>>> is 6Gb/sec capable, but the actual speed is only 1,5GB/sec.
>
>> If your SATA (presumably) connection from the machine to the SSD is a
>> 6 Gbps one, the maximum data transfer speed in bytes across that
>> connection would be one eighth of that (as there's 8 bits per byte),
>> so about 760 MBps.
>
>> That's about half of your "1,5GBps".  That makes me wonder if your SSD
>> uses two SATA channels at once - is that even possible?
>
>Only with SAS drives. And usually only for redudancy and not for
>concurrency.
>
>I question the benchmark Hans did.
>
>Something tells me he either used "hdparm -tT", which is known to
>misrepresent the speeds on modern drives, or wrote too little data so he
>was benchmarking the Kernel cache and not the drive.

I'd assume it's confusion between bits and bytes. For clarity, *never* 
use B or b, just write out bit or byte because some people put attach 
much more significance to the case of that letter than others--making it 
basically useless for communication. As others have already pointed out, 
there's probably a mismatch between SATA versions causing a SATA III 
6Gbit/s device to negotiate down to SATA I 1.5Gbit/s. It's likely that 
the only solution is to replace the SATA controller. (Unlikely to be 
feasible in a portable device.) There is a small chance that it could be 
a bad cable and that replacing the cable would help.

[toc] | [prev] | [next] | [standalone]

#227678

[Multipart message — attachments visible in raw view] — view raw

On Mi, 07 oct 20, 09:06:51, Michael Stone wrote:
> 
> I'd assume it's confusion between bits and bytes. For clarity, *never* use B
> or b, just write out bit or byte because some people put attach much more
> significance to the case of that letter than others--making it basically
> useless for communication. 

SI prefixes can also help... if you use them consistently.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

[toc] | [prev] | [next] | [standalone]

#227679

Hi,

Hans wrote:
> > > Smartctl is telling me, that my ssd drive is 6Gb/sec
> > > capable, but the actual speed is only 1,5GB/sec.
> > > [...]
> > > The notebook is a little bit older, [...]

Andrei POPESCU wrote:
> You would have gotten much better answers by just specifying the exact
> notebook make and model.

... plus the original report lines from smartctl which tell you the speed
value.


Michael Stone wrote:
> > I'd assume it's confusion between bits and bytes. [...]
> > just write out bit or byte

Andrei POPESCU wrote:
> SI prefixes can also help... if you use them consistently.

It is a classic that programs talk mixed about GB and GiB while not clearly
distinguishing them. In general, users must keep the difference in mind when
they compare "GB" values from different programs.
See
  https://en.wikipedia.org/wiki/Mebibyte

Normally i use programmer's units: KiB, MiB, GiB, TiB. Meanwhile this habit
becomes questionable. What was a nice extra of 2.4 percent in the "kilobytes"
era became 4.9 percent with "mega", 7.4 with "giga", and 10 with "tera".
The merchants begin to cheat in the other direction. A 128 "GB" USB stick
might offer only 126 billion bytes a storage capacity.


But in this thread about SSD speed it was most confusing for me to read this:

Hans wrote:
> > And second: If the real transferrate is only 1,5Gbyte/sec, does this mean,
> > that the sata controller is not capable to higher transferrates

No existing SATA can deliver 1.5 gigabytes (+/- 7.4 percent).
So something is wrong in this statement and only original output from
exactly quoted program runs could tell what.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#227680 — [SOLVED] Re: Question: SSD speed

[Multipart message — attachments visible in raw view] — view raw

Hi folks,

I would like to inform you, that due to your responses to my question I got a 
good solution. Although I got the newest BIOS from the vendor, I only got 1,5 
Gb/s for my ssd.

Now I found a hacked BIOS for my notebook with a lot of more settings, flashed 
my notebook, crossed fingers - and it worked!

With the new BIOS I got settings for sata clock (former 133MHz now 200MHz) and 
a clock factor setting from 1-31 (now 16). 

With these settings I got now 3Gb/s , which is doubling the speed. Also other 
settings in this new BIOS like CPU Spread Spectrum and let me well fine tune 
my system. 

Everything is working well with the new BIOS and I am happy with it.

FYI: The notebook is an Acer 7520G with a Phoenix BIOS (which originally is 
really poor with settings). If you have a mainboard with an Award or AMI BIOS, 
you are the lucky guys.

So, thanks to your hints I got the best solution.

Thanks again! 

Cheers and best regards

Hans

[toc] | [prev] | [next] | [standalone]

#227681

On Thu, Oct 08, 2020 at 11:53:16AM +0200, Thomas Schmitt wrote:
>Michael Stone wrote:
>> > I'd assume it's confusion between bits and bytes. [...]
>> > just write out bit or byte
>
>Andrei POPESCU wrote:
>> SI prefixes can also help... if you use them consistently.
>
>It is a classic that programs talk mixed about GB and GiB while not clearly
>distinguishing them. In general, users must keep the difference in mind when
>they compare "GB" values from different programs.
>See
>  https://en.wikipedia.org/wiki/Mebibyte

This is basically never an issue in conversational usage as the 
difference is less than the margin of error or real-world precision. If 
you're planning for a million dollars worth of storage, yeah, make sure 
you're clear on what you're buying. But when discussing a 10Gbit/s 
network or a 4TByte drive, there isn't ambiguity. (Only, potentially, 
pedantry.) 

>Hans wrote:
>> > And second: If the real transferrate is only 1,5Gbyte/sec, does this mean,
>> > that the sata controller is not capable to higher transferrates
>
>No existing SATA can deliver 1.5 gigabytes (+/- 7.4 percent).
>So something is wrong in this statement and only original output from
>exactly quoted program runs could tell what.

Again, there's no real ambiguity here. Since we know that 1.5Gbyte/s 
SATA doesn't exist we've clearly identified that there was confusion 
when reading the original spec (caused by the stupid B/b convention) and 
that 1.5Gbit/s is correct--with enough certainty to simply point out and 
explain the issue and move on.

[toc] | [prev] | [next] | [standalone]

#227683

Hi,

i wrote:
> > It is a classic that programs talk mixed about GB and GiB while not
> > clearly distinguishing them.

Michael Stone wrote:
> This is basically never an issue in conversational usage as the difference
> is less than the margin of error or real-world precision. If you're planning
> for a million dollars worth of storage, yeah,

But what about a 25 cent DVD-R which is labeled "4.7 GB" and only can take
4.377 GiB (4482.625 MiB, 4,700,372,992 bytes) ?

I see such complaints in the web every few months. (With interesting
theories about what might be wrong.)


> Since we know that 1.5Gbyte/s SATA
> doesn't exist we've clearly identified that there was confusion when reading
> the original spec

There could also have been confusion about SATA and NVMe, at least.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#227684

On Thu, Oct 08, 2020 at 03:51:53PM +0200, Thomas Schmitt wrote:
>i wrote:
>> > It is a classic that programs talk mixed about GB and GiB while not
>> > clearly distinguishing them.
>
>Michael Stone wrote:
>> This is basically never an issue in conversational usage as the difference
>> is less than the margin of error or real-world precision. If you're planning
>> for a million dollars worth of storage, yeah,
>
>But what about a 25 cent DVD-R which is labeled "4.7 GB" and only can take
>4.377 GiB (4482.625 MiB, 4,700,372,992 bytes) ?

If the difference matters you want the exact size in bytes. If you're 
willing to round off that many significant digits you weren't that 
worried about the exact size anyway. In 2020 assume you'll need more 
than one and let the computer figure out how to split it.

>> Since we know that 1.5Gbyte/s SATA
>> doesn't exist we've clearly identified that there was confusion when reading
>> the original spec
>
>There could also have been confusion about SATA and NVMe, at least.

Occam's razor suggests not. No need to look for additional remote 
possibilities until the most likely explanation has been ruled out.

[toc] | [prev] | [next] | [standalone]

#227686

> In 2020 assume you'll need more than one and let the computer figure
> out how to split it.

I'm not sure what you're referring to here.  OT1H, from the context
I get the impression you're talking about DVD-R, but OTOH in 2020 the
assumption should rather be not to bother with DVDs any more.


        Stefan

[toc] | [prev] | [next] | [standalone]

#227687

On Thu, Oct 08, 2020 at 11:35:19AM -0400, Stefan Monnier wrote:
>> In 2020 assume you'll need more than one and let the computer figure
>> out how to split it.
>
>I'm not sure what you're referring to here.  OT1H, from the context
>I get the impression you're talking about DVD-R, but OTOH in 2020 the
>assumption should rather be not to bother with DVDs any more.

I thought it was pretty clear, someone asked about fitting stuff on a 
DVD. The answer is that you'll probably need to deal with more than one 
DVD. There is a place for offline backups; DVDs lack in capacity, but 
they're still compelling for that role from a cost standpoint if the 
data volume isn't too high. At any rate, I don't see a point in arguing 
about whether the person I was replying to is doing it wrong because 
they choose to use a DVD.

[toc] | [prev] | [next] | [standalone]

#227688

Michael Stone [2020-10-08 11:44:17] wrote:

> On Thu, Oct 08, 2020 at 11:35:19AM -0400, Stefan Monnier wrote:
>>> In 2020 assume you'll need more than one and let the computer figure
>>> out how to split it.
>>
>>I'm not sure what you're referring to here.  OT1H, from the context
>>I get the impression you're talking about DVD-R, but OTOH in 2020 the
>>assumption should rather be not to bother with DVDs any more.
>
> I thought it was pretty clear, someone asked about fitting stuff on
> a DVD. The answer is that you'll probably need to deal with more than one
> DVD. There is a place for offline backups; DVDs lack in capacity, but
> they're still compelling for that role from a cost standpoint if the data
> volume isn't too high. At any rate, I don't see a point in arguing about
> whether the person I was replying to is doing it wrong because they choose
> to use a DVD.

Looks like I should have included the smiley after all,


        Stefan

[toc] | [prev] | [next] | [standalone]

#227691

On 10/8/2020 8:09 AM, Michael Stone wrote:
> On Thu, Oct 08, 2020 at 11:53:16AM +0200, Thomas Schmitt wrote:
>> Michael Stone wrote:
>>> > I'd assume it's confusion between bits and bytes. [...]
>>> > just write out bit or byte
>>
>> Andrei POPESCU wrote:
>>> SI prefixes can also help... if you use them consistently.
>>
>> It is a classic that programs talk mixed about GB and GiB while not 
>> clearly
>> distinguishing them. In general, users must keep the difference in 
>> mind when
>> they compare "GB" values from different programs.
>> See
>>  https://en.wikipedia.org/wiki/Mebibyte
> 
> This is basically never an issue in conversational usage as the 
> difference is less than the margin of error or real-world precision. If 

	I rather beg to differ.  Many daily operations involve precision better 
than the 2.4% variance between 1000 and 1024.  Certainly my bank account 
balance is maintained to within $.01 of more than $10,000, or 0.0001%. 
I would be fairly distressed if $240 were missing from my account.

	Much of the work I do involves tolerances of less than 1%.

> you're planning for a million dollars worth of storage, yeah, make sure 
> you're clear on what you're buying. But when discussing a 10Gbit/s 
> network or a 4TByte drive, there isn't ambiguity. (Only, potentially, 
> pedantry.)

	Well, what, really, is wrong with pedantry?  As an engineer, precision 
is absolutely of the essence.  What's more, variations become far 
tighter in certain circumstances.  This especially as a container nears 
being full.  If one has 1 MB of storage available (allowing for file 
system overhead and block alignment), then 1 MB of data will fit, but 1 
MiB will not.

	Not only that, but the discrepancy grows exponentially with the order 
of magnitude.  The difference between 1 KB and 1 KiB is only 24 bytes, 
or 2.4%.  The difference between 1 TB and 1 TiB is 9.9%, which is 
getting to be pretty significant.  That, not to mention the fact 93 GiB 
is a pretty good chunk of storage.

[toc] | [prev] | [next] | [standalone]

#227692

Leslie Rhorer wrote: 
> On 10/8/2020 8:09 AM, Michael Stone wrote:
> > On Thu, Oct 08, 2020 at 11:53:16AM +0200, Thomas Schmitt wrote:
> > > Michael Stone wrote:
> > > > > I'd assume it's confusion between bits and bytes. [...]
> > > > > just write out bit or byte
> > > 
> > > Andrei POPESCU wrote:
> > > > SI prefixes can also help... if you use them consistently.
> > > 
> > This is basically never an issue in conversational usage as the
> > difference is less than the margin of error or real-world precision. If
> 
> 	I rather beg to differ.  Many daily operations involve precision better
> than the 2.4% variance between 1000 and 1024.  Certainly my bank account
> balance is maintained to within $.01 of more than $10,000, or 0.0001%. I
> would be fairly distressed if $240 were missing from my account.
> 
> 	Much of the work I do involves tolerances of less than 1%.


That's great, that's awesome; software is actually very good at
dealing with precision and accuracy. 

However, we're talking about people, not software. The people keep being
imprecise. There's nothing that Debian can do about that.

-dsr-

[toc] | [prev] | [next] | [standalone]

#227693

On Thu, Oct 08, 2020 at 01:27:15PM -0500, Leslie Rhorer wrote:
>	Well, what, really, is wrong with pedantry?

It makes conversation with humans harder with no corresponding benefit.

>	Not only that, but the discrepancy grows exponentially with the order 
>of magnitude.  The difference between 1 KB and 1 KiB is only 24 bytes, 
>or 2.4%.  The difference between 1 TB and 1 TiB is 9.9%, which is 
>getting to be pretty significant.  That, not to mention the fact 93 
>GiB is a pretty good chunk of storage.

And how, exactly, does that matter? If you're on your own system and 
looking at output from the same set of programs the units don't actually 
matter at all--you could look and see that you need one foosbit of space 
and have two foosbits and be fine. Units only really matter if you're 
talking to someone else or otherwise taking information out of its 
original context. But I can't even think of a situation where I needed 
to tell someone on a mailing list that I had n TsomethingBsomething of 
space. Context is important. Within the context we're discussing, rough 
order of magnitude is more than precise enough. For humans a 5.4TB drive 
and a 4.9TiB drive both round to 5T. Relative values are generally much 
more important in this context: what percentage of the drive is used? 
what's the rate of consumption? Can debian 11 fit on a 5T drive? If 
you operate in some domain where you need much more precision then go 
ahead and do you, but it pretty much certainly isn't going to be on 
debian-user. 

At any rate here's the cold hard truth: even if you are exchanging 
information and it needs to be precise, humans being what they are it 
won't help you one bit if you're personally pedantic about MiB vs Mb 
because *you can't assume the other side means the same thing*. You'll 
have to establish a baseline in every situation where it matters. But in 
a situation where it doesn't matter, doing so is just a waste of 
time--it won't change the world or human nature.

[toc] | [prev] | [next] | [standalone]

#227704

On 10/8/2020 2:17 PM, Michael Stone wrote:
> On Thu, Oct 08, 2020 at 01:27:15PM -0500, Leslie Rhorer wrote:
>>     Well, what, really, is wrong with pedantry?
> 
> It makes conversation with humans harder

	Can you provide any data to back that up?  I find it often to be quite 
the opposite.  Sloppy use of language very frequently leads to 
miscommunication, sometimes of a very serious nature.

 > with no corresponding benefit.

	There are many benefits to accuracy in communication, and many risks to 
poor accuracy in communication.  Just ask NASA.  Their $328 Million Mars 
Climate Orbiter was lost due to miscommunication between engineering teams.

>>     Not only that, but the discrepancy grows exponentially with the 
>> order of magnitude.  The difference between 1 KB and 1 KiB is only 24 
>> bytes, or 2.4%.  The difference between 1 TB and 1 TiB is 9.9%, which 
>> is getting to be pretty significant.  That, not to mention the fact 93 
>> GiB is a pretty good chunk of storage.
> 
> And how, exactly, does that matter?

	If you don't understand how 1,000,000,000,000 bytes is different from 
1,099,511,627,776 bytes, then I don't know what to tell you.  They are 
not the same.  They are different.  Whether that difference is 
significant or not depends upon the situation.

> If you're on your own system and 
> looking at output from the same set of programs the units don't actually 
> matter at all--you could look and see that you need one foosbit of space 
> and have two foosbits and be fine. Units only really matter if you're 
> talking to someone else or otherwise taking information out of its 
> original context.

	Is there some reason you feel the need to point out the obvious?

> But I can't even think of a situation where I needed 
> to tell someone on a mailing list that I had n TsomethingBsomething of 
> space.

	That is not a reasonable excuse for being sloppy.

> Context is important. Within the context we're discussing, rough 
> order of magnitude is more than precise enough. For humans a 5.4TB drive 
> and a 4.9TiB drive both round to 5T. Relative values are generally much 
> more important in this context: what percentage of the drive is used? 

	Again, that depends upon the situation.  I am certainly not going to 
have a cow if someone accidentally says, "MB", when they mean "MiB", but 
that does not mean it is unimportant everyone should have a solid 
understanding of the difference.

> At any rate here's the cold hard truth: even if you are exchanging 
> information and it needs to be precise, humans being what they are it 
> won't help you one bit if you're personally pedantic about MiB vs Mb 
> because *you can't assume the other side means the same thing*.

	Again, you state the obvious.  The point is, attending to one's 
precision will never hurt.  Failure to do so can.  If one is precise in 
one's speech, then one needn't worry about the situations when 
imprecision can cause an issue.

> You'll 
> have to establish a baseline in every situation where it matters.

	Again you seem to be compelled to point out the obvious.  No 
communication can ever take place without at least implicitly agreed 
upon definitions.

> But in 
> a situation where it doesn't matter, doing so is just a waste of 
> time

	How is it a waste of time?  Imprecision takes no less time than 
precision.  Sometimes it takes more.

> --it won't change the world or human nature.

	Now that is just silly.  Nothing any of us do has more than a minuscule 
chance of changing the world, and less than that of changing human 
nature.  If we were to wait for an opportunity to do something of the 
sort, then none of use would ever do anything.

[toc] | [prev] | [next] | [standalone]

#227706

On Thu, Oct 08, 2020 at 06:49:56PM -0500, Leslie Rhorer wrote:
>
>
>On 10/8/2020 2:17 PM, Michael Stone wrote:
>>On Thu, Oct 08, 2020 at 01:27:15PM -0500, Leslie Rhorer wrote:
>>>    Well, what, really, is wrong with pedantry?
>>
>>It makes conversation with humans harder
>
>	Can you provide any data to back that up?  I find it often to be 
>quite the opposite.  Sloppy use of language very frequently leads to 
>miscommunication, sometimes of a very serious nature.

And yet correcting people in contexts where there's no real ambiguity 
simply derails the conversation and distracts from the real point. 

>> with no corresponding benefit.
>
>	There are many benefits to accuracy in communication, and many risks 
>to poor accuracy in communication.  Just ask NASA.  Their $328 Million 
>Mars Climate Orbiter was lost due to miscommunication between 
>engineering teams.

Context is important. Are you confusing this mailing list with a two 
hundred million dollar science program?

>>>    Not only that, but the discrepancy grows exponentially with 
>>>the order of magnitude.  The difference between 1 KB and 1 KiB is 
>>>only 24 bytes, or 2.4%.  The difference between 1 TB and 1 TiB is 
>>>9.9%, which is getting to be pretty significant.  That, not to 
>>>mention the fact 93 GiB is a pretty good chunk of storage.
>>
>>And how, exactly, does that matter?
>
>	If you don't understand how 1,000,000,000,000 bytes is different from 
>1,099,511,627,776 bytes, then I don't know what to tell you.  They are 
>not the same.  They are different.  Whether that difference is 
>significant or not depends upon the situation.

You dodged the question of how that actually matters, in context. I'm 
just going to stop here, enjoy pedantry.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web