You are not logged in.
Pages: 1
I have this system with two kingston ssds
SATA: sda,50026B76820D72DB,KINGSTON SA400S37120G ,SBFK71E0,N/A,0xdf94bb0,120G,0x0
SATA: sdb,50026B777C0156BA,KINGSTON SA400S37120G ,SBFK71E0,N/A,0xdf94bb0,120G,0x0
If I copy one big file from one to another, using nautilus, cp, rsync, whatever the transfer starts fast (~300MB/sec) but then slows down (~40MB/s) and the cpu usage increase up to 100%
the two involved partitions are ext4
the ouput of hdparm is
sudo hdparm -t /dev/sda
/dev/sda:
Timing buffered disk reads: 1276 MB in 3.00 seconds = 425.14 MB/sec
sudo hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 1164 MB in 3.00 seconds = 387.64 MB/sec
and dd if=/dev/zero of=somefile has similar results. but still the file transfer is slow. One of the partitions is freshly formatted (/dev/sdb1)
Offline
hdparm gives you the best possible numbers. Your copy via rsync, cp etc sounds a bit odd if it causes 100% CPU.
So we'll need a lot more info about the system itself - make and model if it is off the shelf or hardware components if it is self built.
40MBs-1 is about 320Mbs-1 are you sure you are comparing like for like units (Bytes B and bits b)?
Offline
The slowdown that you are seeing is the result of disk buffers and system write caches being maxed out, resulting in your transfer becoming limited by the write speed of the receiving drive. The write speed of SSD's is always slower than the read, often significantly. 40MB/s would seem to be reasonable for writing to an SSD.
An increase in cpu load would also make sense alonside this, although up to 100% would seem high. Is that just for one core?
Offline
hdparm gives you the best possible numbers. Your copy via rsync, cp etc sounds a bit odd if it causes 100% CPU.
So we'll need a lot more info about the system itself - make and model if it is off the shelf or hardware components if it is self built.
40MBs-1 is about 320Mbs-1 are you sure you are comparing like for like units (Bytes B and bits b)?
The slowdown that you are seeing is the result of disk buffers and system write caches being maxed out, resulting in your transfer becoming limited by the write speed of the receiving drive. The write speed of SSD's is always slower than the read, often significantly. 40MB/s would seem to be reasonable for writing to an SSD.
An increase in cpu load would also make sense alonside this, although up to 100% would seem high. Is that just for one core?
Ok, specification time.
GIGABYTE B250M-DH3
INTEL PENTIUM G456
4GB DDR4 2133MH
KINGSTON A400 120GB SSD
I guess they don't come more basic than that, uh? Anyway, it's not some hardware fault because I have built 10 in these guys and all seem to have the same issue. The SSD is this one here and specs are rated for up to 500/450MB sec. If SSD would be stuck at 40MB/s we would be still using hard drives...
Now about the CPU load. Rsync goes to a full 100% cpu load while other seem to only use one core. I guess rsync is multithreaded. Anyway, if we were in the 90s, I would say that there's some problem with DMA, but I don't even know if it's still a thing.
Offline
It would seem I wasn't quite right. Having had a google around, your first figure would be in line with the sequential write speed for your hardware. The second figure ~40MB/s would be in line with the 4k write speed for your hardware.
The first means you are writing to a contiguous unused space on the disk. The second means that you've run out of contiguous unused space and your file is either being split up accross the drive, which is equivalent to writing lots of small files and theredfore has a greater overhead, or it's being written to used sectors which need to be cleared first, hence the lower rate and probably the increase in CPU load.
Offline
It would seem I wasn't quite right. Having had a google around, your first figure would be in line with the sequential write speed for your hardware. The second figure ~40MB/s would be in line with the 4k write speed for your hardware.
The first means you are writing to a contiguous unused space on the disk. The second means that you've run out of contiguous unused space and your file is either being split up accross the drive, which is equivalent to writing lots of small files and theredfore has a greater overhead, or it's being written to used sectors which need to be cleared first, hence the lower rate and probably the increase in CPU load.
I would agree, but we are talking of a brand new ssd, freshly partitioned, freshly ext4 formatted and I was copying a single 20GB file.
Offline
Ok this is not some "hardware" problem. I just dd if=/dev/zero of=/dev/sdb bs=8M and the whole thing copied the whole 120GB @ 300MB/s
dd if=/dev/zero of=/dev/sdb runs at about 40MB/s so it seems that your theory about 4K writing is correct.
But it's not a filesystem problem because I reformatted the thing in XFS and the problem persists.
This is very very strange.
Offline
I thought I pinned it as a partition aligment problem. I'm not so sure about it now. If it is, I'm not able to fix it.
Last edited by riccardocagnasso (2018-05-12 14:51:26)
Offline
I think you've solved this with dd. Using dd with a suitable bs= will ususally be the quickest way for transfering a large file locally.
Partition format shouldn't make a huge difference, though obviously some will have more overhead than others however this will be more noticeable when copying many files, rather than one large one.
Partition alignment will have an impact, but by default parted, fdisk etc shoud auto align. You can of course overide this.
Offline
I think you've solved this with dd. Using dd with a suitable bs= will ususally be the quickest way for transfering a large file locally.
Partition format shouldn't make a huge difference, though obviously some will have more overhead than others however this will be more noticeable when copying many files, rather than one large one.
Partition alignment will have an impact, but by default parted, fdisk etc shoud auto align. You can of course overide this.
Nope. dd if=/dev/zero of=/some/file works fine. (~504MB/S on 20GB)
dd if=/some/file/disk1 of=/some/file/disk2 doesn't (~70MB/S average, that's 40 + the cache i guess)
Which is... weird?
dd if=/some/file/disk1 of=/some/file/disk1 is fast... ish (~240MB/s, as expected slower that write only).
This is getting weirder and weirder
Offline
This problem is too fishy. And it starts to smell like a firmware bug of the SSD. I wrote to kingston, let's see what happens.
Offline
Is that with bs=8M?
If so, you could experiment with different values. Also, changing the input and output buffer size separately.
Also you could look at changing SATA ports for one of the drives in case they are sharing bandwidth. e.g. if you are using 0 and 1, perhaps try 4 or 5 for 2nd disk.
Also how close are these disks to each other? Could be that when both working hard that it's getting too warm for one or both and some kind of throttling is happening? Might explain high speed to start then slowing?
Offline
Is that with bs=8M?
If so, you could experiment with different values. Also, changing the input and output buffer size separately.
Also you could look at changing SATA ports for one of the drives in case they are sharing bandwidth. e.g. if you are using 0 and 1, perhaps try 4 or 5 for 2nd disk.
Also how close are these disks to each other? Could be that when both working hard that it's getting too warm for one or both and some kind of throttling is happening? Might explain high speed to start then slowing?
I did a long list of tests of every kind. I ruled out almost anything. Most importantly, I tried with another model of SSD (an OCZ TRION) and it worked fine.
Now, it still can be a problem of incompatibility between the OS and this model of SSD, but I doubt it. SATA is SATA is SATA.
My best bet at the moment is some bug in this model of SSD's firmware. I'm in contact with kingston technical support and it seems that they are working on it. I will post updates when I know more.
Last edited by riccardocagnasso (2018-05-14 17:58:42)
Offline
Pages: 1