Silicon Motion SM2258XT based ssd slow read! performance

READ Performance on linux any kernel above 6.1 as measured through hdparm (a very basic benchmark but indicative) is very low. Any other ssd i have reads above 500MB/s
windoze speed is ok

Silicon Power Ace A55 1TB, SATA

#SP001TBSS3A55S25

hdparm -t /dev/sdu

/dev/sdu:
Timing buffered disk reads: 1148 MB in 3.00 seconds = 382.07 MB/sec

ADATA Ultimate SU650 960GB, SATA

#ASU650SS-960GT-C
#ASU650SS-960GT-R

hdparm -t /dev/sds
/dev/sds:
Timing buffered disk reads: 1260 MB in 3.00 seconds = 419.74 MB/sec

how are we goint to investigate this?

Continue in any manner you see fit - have fun …

thank you for your help…

Hmm - for what I can see you get what you paid for … why waste time on testing - if you are dissatisfied - ask for a refund.

i understand, but i cannot stand both drive performing as expected on windoze and not on linux

Windows != Linux … they cannot be compared.

I am sure the general performance of your system is with margin.

Never take such applications too seriously - unless your device fail to pass completely.

If you want to experiment

  • try schedulers …
  • tweak your cache, dirty_pages et.al.

The forum has a lot of topics on disk read-write variations - most notably with relation to removable USB storage.

There is even a script somewhere for tweaking certain parameters - search for max-perf-wiz or usb-dev-sync

Samsung SSD 860 EVO 250GB

/dev/sdv:
Timing buffered disk reads: 1620 MB in 3.00 seconds = 539.54 MB/sec

Kingston A400 960GB (phison)
/dev/sdu:
Timing buffered disk reads: 1600 MB in 3.00 seconds = 503.33 MB/sec

same box all

First check if there is a firmware available for your SSDs.

Probably check the alignment on those disks. Here is an old discussion about it: [SOLVED] Poor SSD Performance, Low Buffered Disk Reads / Kernel & Hardware / Arch Linux Forums or here: Setting up Samsung 840 EVO SSDs on Linux – Cillian de Róiste

it is controller specific. the other ssds with phison and samsung controllers work as expected and in windoze all ssds work as expected

i rma the adata and i rechecked both silicon power ace 55 1tb SP001TBSS3A55S25 i get from both read at around 380 MB/s on every machine i tested. adaptec controller intel ich controller amd you name it

Misalignment can certainly cause the slow read that the OP describes.

There was also a recent topic wherein partitions were misaligned during install. A solution was to use gparted specifically to resize the affected partitions (just a little) so that they found better boundaries.

If the OP’s SSD is an external USB type then the controller might play a part.

Misalignment is a distinct possibility.

they are not mounted and there is no partition table because they are wipped…

the benchmark is

hdparm -t /dev/sdv

all other ssds read above 500MB/s (sata ssds)

Perhaps you could have included that information in your original post, to prevent wasted time. You could try swapping to other SATA connectors for a comparison of read speeds.

Beyond that, take it up with the manufacturer.

Update:-

The OP might particularly be interested in an article I found, and this headline:

Team Group’s EX2 is a low-cost SATA SSD that’s great for light work but is outpaced by the slowest of HDDs in sustained write workloads.

That’s taken from a Tom’s Hardware article Team Group EX2 SATA SSD Review: Affordable but Lacking – this SSD uses Silicon Motion’s somewhat dated DRAMless SM2258XT SSD controller, and goes some way to supporting the adage that you get what you pay for.

I submit there is little anyone in this forum can add, except to suggest that you buy a better quality SSD. Samsung is generally good, and so is Western Digital (Black, especially).

That is all.

1 Like

If you didn’t already do - please the the man page for hdparm

Of particular interest

       --direct
              Use the kernel´s "O_DIRECT" flag when performing a  -t
              timing  test.   This  bypasses the page cache, causing
              the reads to go directly from the drive into  hdparm's
              buffers,  using  so-called  "raw" I/O.  In many cases,
              this can produce results that appear much faster  than
              the  usual  page cache method, giving a better indica‐
              tion of raw device and driver performance.

unfortunatelly i tried --direct too. only when there is some io load the hdparm score changes
i tried two sp ssds and one adata all read below 400MB/s
it is either deliberatelly done by SM2258XT controller so you will not be able to raid a few of these chip ssd OR the ssd flash chips are ■■■■

That’s why I tell you about alignment.

There is a difference between /dev/sdv and /dev/sdv1. If the first partition is aligned correctly, you would get better results, what the discussion on the ArchForum above proves. It’s about the start sector or “Partition Starting Offset”.

So the first partition should start at ~1.5K, commonly used 2048, also 4096 improves read/write on SSD’s. That is not a big secret.

same command (raw device read) all other ssd fly above 500MB/s

i run this command just to verify that ssd runs as expected. it is very primitive way to test speed.

View up 3:11 min

i saw that video already. we don’t care about write speed since the ssds will be used on a raid array , we care about READ speed. ssd read fast unless there is something wrong with the controller (i assume silicon motion firmware is buggy) OR crappy flash chips. it this case write speed suffers more.
tha adata su650 that i sent back had the same controller, better flash chips but same low READ speed.
in windows both drives work as expected. not as fast as a samsung but ok. again my problem is slow READ speed

what a Raid Level use ? and what filesystem ?

hdparm should not be used to benchmark a RAID, because it provides very inconsistent results.