Re: Question: SSD speed
>>> 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
Re: Question: SSD speed
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.
Re: Question: SSD speed
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.
Re: Question: SSD speed
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.
Re: Question: SSD speed
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.
Re: Question: SSD speed
> 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
Re: Question: SSD speed
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.
Re: Question: SSD speed
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-
Re: Question: SSD speed
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.
Re: Question: SSD speed
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
Re: Question: SSD speed
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.
Re: Question: SSD speed
> 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
Re: Question: SSD speed
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.
Re: Question: SSD speed
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
Re: Question: SSD speed
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.
[SOLVED] Re: Question: SSD speed
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 signature.asc Description: This is a digitally signed message part.
Re: Question: SSD speed
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
Re: Question: SSD speed
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 signature.asc Description: PGP signature
Re: Question: SSD speed
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 signature.asc Description: PGP signature
Re: Question: SSD speed
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 signature.asc Description: PGP signature
[SOLVED] Re: Question: SSD speed
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 signature.asc Description: This is a digitally signed message part.
[SOLVED] Re: Question: SSD speed
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 signature.asc Description: This is a digitally signed message part.
Re: Question: SSD speed
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
Re: Question: SSD speed
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.
Re: Question: SSD speed
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 signature.asc Description: This is a digitally signed message part.
Re: Question: SSD speed
On Wed, Oct 07, 2020 at 12:48:09PM +0200, Sven Hartge wrote: Jeremy Nicoll 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.
Re: Question: SSD speed
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.
Re: Question: SSD speed
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?
Re: Question: SSD speed
Jeremy Nicoll 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.
Re: Question: SSD speed
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.st...@einval.com "You can't barbecue lettuce!" -- Ellie Crane
Re: Question: SSD speed
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.
Re: Question: SSD speed
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 > > > >
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
