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
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 gpartedspecifically to resize the affected partitions (just a little) so that they found better boundaries.
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).
--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 ā ā ā ā
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.
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