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
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.
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.
If the OP believes the issue is due to the SSD controller (which I also believe is likely), what is hoped to be achieved here?
to verify that there is nothing silly happening with the kernel or there is needed some extra config.
otherwise bring this to “silicon power” attention for a new drive firmware or so
hdparm is just to verify that speed is according to spec
people use raid6 with xfs or f2fs (i am experimenting on both)
Neither of these are likely, in my opinion.
Perhaps ask in the forum before you buy a new SSD, rather than after, when it doesn’t meet expectations. I’m aware some SSD’s are not as affordable as others in the marketplace, nonetheless try not to buy solely based on price, if possible (we’ve all been burnt at some point).
it is not about meeting expectations. it is very very strange that READ speed is slow. on every drive with SM2258XT SSD controller i tested and ONLY on linux