I have a question about testing the speed of writing to a device.
To be more exact: It´s a new usb-stick of mine which I want to test.
Is there a terminal command (or a package to be installed) with the help of which I can test the speed
I´m particularly interested in the speed of writing to the device as I suspect it´s a bit slow.
Well, the stick itself is connected to a USB 2.0 port and therefore it should be clear that the speed of writing isn´t all too fast.
Still: I´d like to get the exact values, if at all possible, in order to be able to compare them.
The thing however is: There´s already quite a lot of data on the stick that I don´t want to lose.
So if any command for my purpose would need the whole of the stick or even deletes all of its contents, this wouldn´t be the thing I´m looking for.
Basically the command should write to a dedicated part of the stick only (e.g. a special folder) to provide me with the info I´d like to get.
Does anyone know if there´s a command than can do that
I found 2 others things that will affect how fast your PC can read / write to the USB Flash (Stick) drive.
USB 2.0 ports.
“USB 2.0 clock speed is 480 megabits per second. That’s 60 megabytes per second. Given the protocol overhead and the fact that USB 2.0 is half-duplex, the maximum data rate will be 30-40 megabytes per second. The 480 megabits per second limit applies to the USB controller and is shared between the ports attached to it. The number of USB controllers per card or motherboard will vary.”
And I found this chart showing the max speed of USB flash drives. The flash drive should either show this code or it should be shown in the packaging.
I paid paragon software what seems an exhorbitant ($40+ is not cheap) license fee to use their ext4 “driver” on MacOS (and it will only let me use it on ONE COMPUTER!) so I could share ext4 thumb drives with my Linux machines…
Just hit a wall - upgraded my personal MacBook Pro to MacOS 13.4 (from 12.62) and it broke that piece of crap driver and I lost my Resilio Sync share on it…
Reformatted as APFS (encrypted) now and having to sync ~200 GB of data over the network (NFS on ethernet)… IF I need to get files on it, or off it - I’ll just use scp or rsync or something…
So a big FU to Paragon Software! Thanks for nuthin’!
Also - I also updated my work issued MBP (M1) to Ventura earlier - and didn’t hit this issue - because I wasn’t using ext4… The only reason I use a thumb drive on my personal MBP is it only has 256 GB SSD - so I offload my bigger Resilio Sync “sync targets/sources” onto external storage (I have a FAST USB C, USB 3.2 thumb drive for this purpose)…
If I can’t use SCP / rsync to copy data, I can just use a Fat32 USB drive… I’ve like over 30 of them 8 GB or over… My Ventoy stick is visible on the MacBook (not that I’d try to boot it - I’m quite happy with Mac OS X / UNIX - don’t need Linux on arm64 / M1 / Apple Silicon thank you very much).
While we are on USB sticks, I gambled $10 on a 1Tb stick. It came with instructions in some foreign script. It is only usb2.0. It does work… at least i plugged it in and the computer could see its filesystem.
How do you reckon it will perform? What is the life expectancy ?
I might try Rosika’s fio speed test.
I found “Benchmark disk” in the application. I have to do some research on it first as I don´t know whether this option would destroy any data on the stick or whether it works in a similar way as fio does.
Thanks, Neville, for the confirmation.
That was my guess, too, but I wanted to be sure.
I see. Well, I hadn´t thought of that.
The stick in question is a “Verbatim STORE N GO (PMAP)” model.
I originally purchased it as a storage medium for recording programmes with my DVB-T2 receiver (terrestial digital TV).
It proved to be less than optimal for my purposes, so I decided to use it with my PC instead.
It was already formatted in FAT32 and I also compared it to the other USB-sticks I have attached to the PC and they are FAT32 as well. So I just left the formatting as it was.
The reason for getting interested in the write performance of the stick is:
I was copying data from another USB-stick (but also from the external HDD) to this Verbatim-stick.
I was using rsync for that:
Fortunately I took a screenshot of the terminal at the time to see what the different write speeds were. I marked them in red:
Copying a large number of small files is more work than copying fewer large files.
If there is already something on the disk, rsync has to do reads as well as writes.
Rsync uses the cpu, if the computer is busy it will share time between the copying and other jobs.
What are those rsync errors?
You are reading one usb stick and writing another. The usb data bus may be very busy.
It still seems rather a large difference to me.?
Try mounting it with a mount statement and setting async
Flash drives are way much slower for writing, than reading, whereas HDD’s perform the same for reading and writing (usually )
Recently I fill up 64GB thumbdrives with the same content, so did the fillup once, imaged that drive, and put the image onto the copies with dcfldd.
Filling up the ‘master’ drive took about 3 hours, copying the images take about 2 hours.
While doing the copy, sometimes watch the process with iostat, and I see transfer speeds about 12MB/s.
The drives are USB3 Kingston G3 (or Exodia, which I got cheaper). Reading from these drives are blazing fast, I get speed about 90MB/s.
So writing to a flashdrive is slower, maybe much slower than the speed specification of that thumbdrive.
I just asked ChatGPT (to have a quick result) and this is what it had to say about it:
The error message you encountered while using the rsync command indicates that the process was terminated by a signal. Here’s the breakdown of the error message:
rsync error: received SIGINT, SIGTERM or SIGHUP (code 20) at io.c(518) [generator=3.2.7]
This part of the error message suggests that the rsync process received a signal, which could be one of the following:
SIGINT: This signal is sent when the user interrupts a process by pressing Ctrl+C in the terminal.
SIGTERM: This signal is typically sent to terminate a process.
SIGHUP: This signal is sent when the terminal session is disconnected or closed.
rsync error: received SIGINT, SIGTERM or SIGHUP (code 20) at rsync.c(713) [sender=3.2.7]
This part of the error message further specifies that the signal was received within the rsync sender code.
These signals usually indicate that the rsync process was interrupted or terminated prematurely.
It’s possible that the process was manually interrupted by pressing Ctrl+C or that some external factor caused the termination, such as a loss of connectivity or an issue with the source or destination drive.
To avoid such interruptions and ensure smoother copying, you can try the following: […]