On 2024-11-17 14:00, Stephen Morris wrote:
On 17/11/24 18:02, Tim wrote:
Chris Adams:
That's a misunderstanding of how things work. The SATA port speed is
just an upper-bound on transfer, but has nothing to do with how fast a
device can actually read data (similar to having a 1G network card and
even Internet service doesn't mean sites will serve data to you at 1G).
Traditional spinning hard drives typically do top out in the
neighborhood of 150 MB/s... and in fact, the official spec from Seagate
for that drive is an average read rate of 156 MB/s.
Is that really megabytes or megabits per second?
The bench mark speeds are megabytes per second and the quoted disk
performance speeds and the port speed is megabits per second, and
looking at the performance I might try hdparm and see what it says for
raw reads and cached reads, assuming my hard disk has cache (I haven't
checked that spec yet).
The cached reads are referring to the system cache, not the hard drive.
It's not accessing the hard drive at all for that test.
And the converse applies to Stephen, remember when you're measuring one
thing against another, and they use the two different things. Convert
gigabits per second into megabytes per second, and it seems far less
impressive. Even more so when they mix up the usage of 1024 or 1000
bits and bytes multipliers.
Stephen Morris:
If that is the case why does the specs for that device under
performance say it will support speeds of 1Gb/s, 3Gb/s and 6Gb/s.
Because big numbers are a marketing ploy... Sure, there's *something*
that the SATA port can do at that speed, but it's not continuously
churn your data through in the way that you'd like.
Yes, I understand that but when the device specs specify that the device
can operate at 1Gb/s, 3Gb/s and 6Gb/s and the device is plugged into a
6Gb/s port, I expect it to operate at the faster end of the range, but a
benchmark speed to 156GB/s says that it is not.
This was explained in another email. It doesn't matter how fast the bus
is, the hard disk can only read so fast. The specs say that the disk
will work with any of those bus options. And the data that is read will
be transferred at those rates. But the overall rate is still limited by
the disk.
If they put high speed cache between SATA port and internal storage,
they can increase data through-put up to a point (to the point where
it's filled the cache). So it's quick for storing one or two very
large files, because they're measuring the SATA data speed. But
internally, the cache is transferring over to the storage medium at a
much slower rate.
Yes, a full cache can cause performance issues, but I would expect to be
able to play around with the caching algorithms to control what gets
cached and what doesn't, particularly when looking at sequential vs
random access, combined with disk fragmentation. I know EXT4 is a
journaling file system which is supposed to make fragmentation a non-
issue, but I don't know whether BTRFS is the same.
That's not the cache that's meant. He was referring to the hard disk
internal cache. You have no control over that. The filesystem could be
a factor for seek times, but it shouldn't be that much.
I remember when IDE went over to UDMA (same two inch wide [approx] fat
ribbons, with twice the wires in them). It could achieve much higher
data speeds across the cable, but the drive medium was a bottle neck.
Then they put cache RAM in the drives, and that allowed more data to be
quickly dumped across the cable to the drive, but the same problem
existed: Once the cache was full, you're down to the slow speed of the
storage medium inside the drive.
I know that can be an issue and the issue can be compounded by deferred
writes causing data to remain in cache for longer.
Again, this was referring to the cache on the hard disk, not the system
cache.
--
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
