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 2 of 2 — ← Prev page 1 [2]

#227707

On 10/8/2020 7:10 PM, Michael Stone wrote:
>>     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.

	I will concede that can happen, but the point is divergent from mine. 
There is a difference between taking care one's own speech is precise, 
making a general request that people take care with their speech, and 
correcting someone else's speech.

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

	I made a general statement that holds true for both.  I am not 
confusing anything.  Whether context is important or not is beside the 
point.  Whether three hundred million dollars is at stake or not, 
precision will serve one well.

>>> 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.

	What does "mattering" have to do with it?  Different is different.  By 
simply being consistent and precise, one needn't worry about whether 
something "matters" or not.  The situation is much like any other good 
habit.  Being habitually precise covers one whether the situation is of 
great import or not.

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

#227702

> 	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.

In which way is the KB-vs-KiB discrepancy different from the "file
system overhead and block alignment"?

Maybe it's a higher percentage, but the end result is the same: if your
FS says you have N bytes left, it does not guarantee you that an N byte
file will fit, so you need to include some slack.  And since very few
people are able to quickly compute how many blocks are needed for
a file of size N on the specific filesystem they use, you're better off
using a "safe enough" estimate.  This notion of "safe" enough is one
learned empirically over the years, so whether it's 2% or 10% doesn't
really matter that much, as long as it's pretty much always the same.

> As an engineer, precision is absolutely of the essence.

When talking about the capacity of mass storage, you don't need
precision, since it just has to be large enough, rather than having to
have exactly the right size.

Engineers are very familiar with such imprecise constraints and with
the use of safety margins to account for them.


        Stefan

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

#227705

On 10/8/2020 5:13 PM, Stefan Monnier wrote:
>> 	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.
> 
> In which way is the KB-vs-KiB discrepancy different from the "file
> system overhead and block alignment"?

	File system overhead is not primarily an artifact of the size of the 
blocks.  Block alignment is related to the size of the blocks, but then 
I never said it was not.

> Maybe it's a higher percentage, but the end result is the same: if your
> FS says you have N bytes left, it does not guarantee you that an N byte
> file will fit,

	If it says you have 1.00 MB free, then it is guaranteed 1.00 MiB will 
not fit.  If it (accurately) says you have 1.00 MiB free, then 1.00 MB 
is indeed guaranteed to fit.

> so you need to include some slack.

	Not usually that much.  Again, it depends on the situation.

> And since very few
> people are able to quickly compute how many blocks are needed for
> a file of size N on the specific filesystem they use, you're better off
> using a "safe enough" estimate.  This notion of "safe" enough is one
> learned empirically over the years, so whether it's 2% or 10% doesn't
> really matter that much, as long as it's pretty much always the same.

	Well, the point is it isn't the same.  One PiB is 1,125,899,906,842,624 
bytes.  One PB is 1,000,000,000,000,000 bytes.  That is a difference of 
12.6%, vs. 2.4% difference between 1 KiB and 1 KB.


>> As an engineer, precision is absolutely of the essence.
> 
> When talking about the capacity of mass storage, you don't need
> precision, since it just has to be large enough, rather than having to
> have exactly the right size.

	Indubitably, but a 12.6% shortfall would be a problem.

> Engineers are very familiar with such imprecise constraint and with
> the use of safety margins to account for them.

	Of course I am.  There are plenty of cases where a safety margin is 
required.  There are plenty of other cases where a tiny differential can 
mean the difference between working well and a catastrophic failure. 
Direction also matters.  A cylinder that is just 0.001 mm oversize will 
not fit in a hole that is 0.001 mm undersize.

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

#227710

>>> 	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.
>> In which way is the KB-vs-KiB discrepancy different from the "file
>> system overhead and block alignment"?
> 	File system overhead is not primarily an artifact of the size of the
> 	blocks.  Block alignment is related to the size of the blocks, but
> 	then I never said it was not.

The question is not about underlying technical details, but about the
result when it look at it as a "black box".

>> Maybe it's a higher percentage, but the end result is the same: if your
>> FS says you have N bytes left, it does not guarantee you that an N byte
>> file will fit,
>
> 	If it says you have 1.00 MB free, then it is guaranteed 1.00 MiB
> 	will not fit.  If it (accurately) says you have 1.00 MiB free, then
> 	1.00 MB is indeed guaranteed to fit.

[ Actually, not necessarily.  I can imagine filesystems where that could
  fail (either because they include an insane amount of metadata, or
  because they only support files made of consecutive blocks and there
  is no hole large enough to fit that 1.00MB file).
  But, yes, in practice the 5% slack of MiB-vs-MB should always be
  larger than the filesystem's overhead.  ]

>> so you need to include some slack.
> 	Not usually that much.  Again, it depends on the situation.

Yes, it depends.  Hence the need for guessing and approximation.

>> And since very few
>> people are able to quickly compute how many blocks are needed for
>> a file of size N on the specific filesystem they use, you're better off
>> using a "safe enough" estimate.  This notion of "safe" enough is one
>> learned empirically over the years, so whether it's 2% or 10% doesn't
>> really matter that much, as long as it's pretty much always the same.
>
> 	Well, the point is it isn't the same.  One PiB is
> 	1,125,899,906,842,624 bytes.  One PB is 1,000,000,000,000,000
> 	bytes.  That is a difference of 12.6%, vs. 2.4% difference
> 	between 1 KiB and 1 KB.

That's true.  But during a given year, most people will only be faced
with sizes that are within more or less the same range.  E.g. most
people nowadays are commonly faced with the 7.3% difference of
GiB-vs-GB so it's likely the slack they will implicitly assume.
Every ten years or so you'll need to adjust this slack to your new
reality manipulating larger data, but since it happens gradually it's
not that big of a deal.

>>> As an engineer, precision is absolutely of the essence.
>> When talking about the capacity of mass storage, you don't need
>> precision, since it just has to be large enough, rather than having to
>> have exactly the right size.
> 	Indubitably, but a 12.6% shortfall would be a problem.

I'm pretty sure people do use PB-size datasets nowadays and I haven't
them complain about PiB-vs-PB problems, so I'm not worried.

> 	Of course I am.  There are plenty of cases where a safety margin is
> 	required.  There are plenty of other cases where a tiny differential
> 	can mean the difference between working well and a catastrophic
> 	failure. Direction also matters.  A cylinder that is just 0.001 mm
> 	oversize will not fit in a hole that is 0.001 mm undersize.

Indeed, but mass storage isn't in that category.  When you buy a drive
of size S you know you definitely won't be able to fit a dataset of size
S onto it but it's not straightforward to know exactly how large
a dataset will fit.  In order to know the actual space you'll have
available you need to account for many overheads and approximations, and
in 99% of the cases you also need to account for the fact that the size
of the data you'll put on it isn't precisely known yet either
(especially since if it's large there's a very good chance that it'll be
compressed to some extent).

So except for very unusual cases, this is firmly in the camp of "guess
the approximate size you need, then multiply by N" or something along
the lines.


        Stefan

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

#227654

Just a small correction: it I believe SATA uses 8B/10B protocol, which 
means each byte uses 10 bits on the serial channel.

On 10/7/20 5:56 AM, Jeremy Nicoll wrote:
> 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?
>

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

#227655

On Wed, 7 Oct 2020, at 12:14, Alberto Sentieri wrote:
> Just a small correction: it I believe SATA uses 8B/10B protocol, which 
> means each byte uses 10 bits on the serial channel.

I didn't know that.  Divide bps by ten to get Bps is the rule of thumb I
use for things like broadband connections, to allow for protocol
overhead.

-- 
Jeremy Nicoll - my opinions are my own.

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

#227676

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

On Mi, 07 oct 20, 13:31:49, Jeremy Nicoll wrote:
> On Wed, 7 Oct 2020, at 12:14, Alberto Sentieri wrote:
> > Just a small correction: it I believe SATA uses 8B/10B protocol, which 
> > means each byte uses 10 bits on the serial channel.
> 
> I didn't know that.  Divide bps by ten to get Bps is the rule of thumb I
> use for things like broadband connections, to allow for protocol
> overhead.

In the times of 56k modems I've seen 9 suggested as a divider, to allow 
for protocol overhead and some compression (assuming the data itself is 
not compressible).

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

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

#227660

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

Hi all,

thanks for the reponse. However, it looks, I did not ask clearly enough.

So let me ask again: If the ssd supports 6Gbyte/sec transferrate, is there the 
option to set the controller of the motherboard also to 6Gbyte/sec?

And second: If the real transferrate is only 1,5Gbyte/sec, does this mean, 
that the sata controller is not capable to higher transferrates or does it 
possibly mean, that my configuration is wrong?


Thanks for any answers.

Best regards

Hans

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

#227661

On Wed, 7 Oct 2020, at 17:40, Hans wrote:
> Hi all,
> 
> thanks for the reponse. However, it looks, I did not ask clearly enough.
> 
> So let me ask again: If the ssd supports 6Gbyte/sec transferrate

It doesn't.  It's 6 giga bits per second which means about 600 megabytes.

>, is there the 
> option to set the controller of the motherboard also to 6Gbyte/sec?

I think you'd need to check the specific motherboard model and possibly 
its firmware with its manufacturer. 

No-one else will know.


> And second: If the real transferrate is only 1,5Gbyte/sec, 

No, that's 1.5 giga BITS pr second... so about 150 megabytes/sec.

> does this mean, 
> that the sata controller is not capable to higher transferrates or does it 
> possibly mean, that my configuration is wrong?

You need to find out what your hardware is capable of.



-- 
Jeremy Nicoll - my opinions are my own.

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

#227662

Hello,

On Wed, Oct 07, 2020 at 06:40:01PM +0200, 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 or does it 
> possibly mean, that my configuration is wrong?

This is all meant to be automatic. If you have some reason to
believe that your SATA/SAS controller is 6Gbit/s and your storage
device is 6Gbit/s but it comes up as less than that, then that's a
problem/bug/fault and not something that you generally just set.

And even with a 6Gbit/s negotiated link, you aren't going to achieve
6Gbit/sec of data transferred.

Start by working out what hardware you have to see what it's
actually meant to be capable of. Then you'll see if you have a
problem or if the behaviour is expected.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

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

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

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

Am Mittwoch, 7. Oktober 2020, 19:39:46 CEST schrieb Andy Smith:
Hi Andy,

that is exactly, what I wanted to know! So it is just a hardware part, not a 
problem in my configuration.

Thanks for the help!

This thread is now fully solved. Thank you all for your time and all your 
informations.

Best regards

Hans



> Hello,
> 
> On Wed, Oct 07, 2020 at 06:40:01PM +0200, 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 or does it
> > possibly mean, that my configuration is wrong?
> 
> This is all meant to be automatic. If you have some reason to
> believe that your SATA/SAS controller is 6Gbit/s and your storage
> device is 6Gbit/s but it comes up as less than that, then that's a
> problem/bug/fault and not something that you generally just set.
> 
> And even with a 6Gbit/s negotiated link, you aren't going to achieve
> 6Gbit/sec of data transferred.
> 
> Start by working out what hardware you have to see what it's
> actually meant to be capable of. Then you'll see if you have a
> problem or if the behaviour is expected.
> 
> Cheers,
> Andy

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

#227671 — [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]

#227677

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

On Mi, 07 oct 20, 10:39:44, 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.

You would have gotten much better answers by just specifying the exact 
notebook make and model.

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web