Puppy Linux Discussion Forum

DriveSpeed!

Afternoon, gang.

I got the idea for this from playing around, and 'tinkering' with BK's 'EasyDD' script, for which I put some packages together a couple of years ago. One thing I noticed about the script was that when writing the ISO .img file to the drive, it also gave an on-going, 'live' readout of the drive's write speed as it happened. I thought this was quite useful; I know you can do all sorts of things with 'dd', so I decided to look into using this function - along with a 'read' version - as part of a 'speed tester' utility.

Further 'head-scratching' ensued from this thread:-

viewtopic.php?f=2&t=2769

Some scouting around the 'net brought up this page from BlackmoreOps:-

https://www.blackmoreops.com/2017/04/04 ... -in-linux/

.....which provided some very useful information. Along with studying BK's 'easydd' script, I sooner or later had a bunch of wee scripts fleshed out for checking read/write speeds of a flash drive, along with a YAD-powered GUI for controlling it all!

--------------------------------------------------

This should work with any 'external' drive; USB-flash, USB HDD, USB SSD, SD cards, zip drives.....you name it; if 'dd' can write to/read from it, DriveSpeed! will work.

By means of Fred's 'readlink' trick - which I've used extensively in my other portable applications - DriveSpeed! can be used anywhere. Download it; unzip it. Copy it to ANY drive you wish to test read/write speeds of; the 'testfile' will be created in-situ, so really, anywhere on the drive will do. The initial test will be the write-test; DriveSpeed! will create a 'dummy' file of 1 GB in size, called 'testfile', using the 'dev/zero' function of 'dd'. By making use of the 'status=progress' flag, along with a couple of others, a wee RXVT terminal window opens, showing progress of the operation along with a real-time 'speed' display of the data transfer.

The subsequent test is then the read-test. DriveSpeed! reads the contents of the 'testfile', and dumps it into the black hole of /dev/null as it does so. Again, a wee RXVT terminal window monitors progress, and keeps you informed.

You can run these tests with a choice of 'block sizes'; I've chosen 'bs=256k", "bs=512K", and "bs=1M" for this. You don't have to stick with the same block size for both tests; if you wish, you can choose different ones.

------------------------------------

PLEASE REMEMBER:- Clear the drive's cache buffers by use of the 'CLEAR BUFFERS' button between tests. This helps to give a more accurate representation of the drives caching performance; it's beneficial to start with a "clean slate" for each run!

An 'explainer' is available from the 'HELP' button at any time.

-----------------------------------

DriveSpeed! is NOT intended to be an exhaustive drive test utility. Its sole purpose is to test drive read/write speeds, and that's what it does. It's probably not up to some of your standards, but don't get on to me, guys; it follows the Linux mantra of doing one thing only, yet attempting to do it as well as possible.

I've tested this with quite a collection of USB 2.0 & USB 3.0 drives, in both USB2 & USB3 ports, across a selection of Puppies of both 'arches'. It functions quite happily, since it's simply making use of your existing 'dd' binary.

I've attached the tarball to the bottom of this post.

EDIT:- (05/05/21) - New version v3 released. Improvements include partition selection/mount facility, and auto-scanning for all available partitions on the system before populating the combo-box "drop-down".

EDIT:- (06/05/21) - New version v4 released. As above; additions include progress window now within the GUI; you can abort the test early, and clear the data - handy if you have very slow drives and just want to run long enough to get a meaningful readout.

See HERE for details. Thanks to stemsee for the additions.

EDIT:- (08/05/21) - Final versions of v4. Also, a slightly-modified v2.1, with contributions from the other 'Mike' in this thread.

-------------------------------------

This is the first time, I think, that I've attempted to build a utility from the ground up. Feedback will be appreciated; constructive criticism is welcome.....criticism purely for the sake of criticism, not so much.

Let me know what ya think, please, kiddiwinks.

Mike.

Thanks for this!

You know, computers can do a lot of things.
But are they really things we need to do!

Any information is a good thing!
I can see using this to test a USB drive or USB port, that may be going bad.

Thanks!

Anyway to have a drive selection option?
Select what drive to test.

Note:
This will run in EasyOS Dunfell 2.6.1 released for Raspberry Pi4

bigpup wrote: Mon May 03, 2021 3:36 pm

Thanks for this!

You know, computers can do a lot of things.
But are they really things we need to do!

Any information is a good thing!
I can see using this to test a USB drive or USB port, that may be going bad.

Thanks!

Anyway to have a drive selection option?
Select what drive to test.

Note:
This will run in EasyOS Dunfell 2.6.1 released for Raspberry Pi4

@bigpup :-

Well, now, y'see, that's why I made it a portable application.

• a) Because I didn't think it was the sort of thing folks would want to have permanently installed, and

• b) It would need re-writing to include a drive selector, and the associated 'junk' that goes with that.....and *sotto voce* my coding skills aren't quite there yet!

This way, drive selection is taken care of by dragging it onto whatever drive you want to test.....it's written to perform the tests 'in-situ', wherever it happens to be located.

Ya gotta do stuff according to your abilities, mate. I'm getting there.....but I'm not there yet, y'know? As it stands, for a .pet package a "selector" would be a must, and I'm still figuring that stuff out, ATM. And if I put this on the "back-burner", while learning more new skills, I rather think by the time I'd acquired those new skills I would have also lost the momentum of what I was trying to achieve.....

It can always be "re-worked" at a later date.

(*shrug*)

BTW - nice to hear it works in places I haven't tested yet. Cool!

Mike.

Thanks Mike, I think it's OK, if I could read the output window I might know. My text came up white, with ffff80 (pale yellow) background. Made it hard for old eyes. So I changed the background colour in one of the sub-scripts, all good now.

Edit: Added -foreground '#000000' to script, so black on yellow now looking good.

Edit 2: The read speed on my internal SSD was so quick the box flashed up and disappeared so quick I couldn't read anything.
Doing some more checking, this appears to be mainly the 1Mb read. I tried an USB 3 flash drive, 1Mb still just a flash, the 256 K and 512 K, stayed visible and showed 120~130 Mb/s

@TerryH :-

Well, I'm glad to hear it works for you, but.....white text? Sheesh..... I can't ever remember seeing a /root/.Xdefaults file set to anything other than black text, so I didn't bother specifying that one. (Reminds me of Tahrpup's original terminal; d'you remember it? Pale green text on a pale-blue background.....what WAS Phil thinking of? Dearie me.....)

Yes, I've been quite surprised at just how fast some of these modern drives are. I've got a wee, 'nano'-sized, USB 3Gen2 SanDisk Ultra fit 32GB drive. Much older drives, reads aren't much better than 12-15 MB/s; this wee SanDisk, anywhere from 95-125 MB/s.....though even THAT seems to vary, depending on the port in use.

I'm working on learning how to capture the output from a YAD 'combobox', so that for a future release I can do away with multiple, nearly identical scripts, and just have the one using variables from that instead. If I ever get the hang of 'em, I may incorporate block-size choices, and also file-size choices from comboboxes into it as well. These will be required before I can provide this as a .pet package, anyhow. Early days yet, mate; gotta learn to walk before I can run..!

Simple 'substitution' variables I can do in a script; multiple-choice stuff, I'm not so sure about yet.....

Mike.

mikewalsh wrote: Mon May 03, 2021 8:12 pm

Yes, I've been quite surprised at just how fast some of these modern drives are. I've got a wee, 'nano'-sized, USB 3Gen2 SanDisk Ultra fit 32GB drive. Much older drives, reads aren't much better than 12-15 MB/s; this wee SanDisk, anywhere from 95-125 MB/s.....though even THAT seems to vary, depending on the port in use.

Yes, the USB I was using was on of the same SanDisk UltraFit, you hardly notice it is there. Equivalent speeds to traditional spinning disk HD's.

Was using Fatdog 811, it think that the white text is OOTB, or don't remember changing it.

mikewalsh wrote:

Feedback will be appreciated; constructive criticism is welcome

Couple ideas for consideration

• I saw the device selection mentioned by @Bigpup and thought this, too, would be an addition which might be an advantage: The ability to have the multiple sizes as a drop-down, with a default in the window for read/write; namely these four are typical blocksizes used most frequently, 256KB, 512KB, 1MB, 4MB.

• A log of tests (or option for a log)

If applicable, I'm sure it will be in the future versions.

The screen's button are applicable: I like the wording and capitalizations.

Use of the drop-down approach, vs the statics, will reduce screen real-estate.

This will go a long way toward keeping a diary of the too-many USB sticks I have. Past performance measures show all kinds of performances that I need to label by PC-port-performance-manufacturer of sticks.

These 2 other puppyland threads on USB use are applicable information for PUP users. And could be helpful in spotting rea/write issues that this utility might report:

• Here1

• and Here2

This, of course, is consistent with the discussion you mentioned, "head scratching" earlier here.

This could become a PUP utility that finds its way into the stream providing a standard manner to measure USB behavior.

Just a few ideas.

Hi @TerryH

I am using this, "SanDisk Ultra USB 3.0", but the overall performance is horrible, at best, on the PC it is attached. My past findings is not good with few of my past USB-HDDs vastly outperforming my flash. So, I have limited my writing and use them mostly for reads; thus they exist primarily for data stores.

Maybe one day, I will spend the extra money for more expensive flash to see if I can attain the 100MB+ speeds I have heard about. Highest speeds couple of my USBs have shown is 13MB/sec

Just some personal findings of my USBs.

@Clarity :-

Keeping within the utility's stated goals, i.e., that of being a speed-tester - no more, no less - there ARE ideas for how I'd like to 'tidy it up', yes. But before I can achieve what I want, I need to expand my scripting skills-sets further yet!

This IS very much a 'Mark 1' version, I don't mind admitting. I wanted to get the basic mechanisms in place, and functional; the GUI appearance/layout, while they ARE important to me, personally (I've never liked things to look like 'amateur night'), can always be tidied-up/enhanced/improved at a later date.

I'm also aware that no matter how much I espouse the 'portable' format, most Puppians still prefer the traditional mix of .pet & SFS packages. An SFS package this small seems a bit silly; a .pet I can certainly do, though a few tweaks will be necessary to accommodate its henceforth 'static' location.

Bear with me. I'm learning as I go! I'm nowhere near 'finished' with this yet...

(EDIT:- The USB 3.0Gen2 SanDisk Ultra 'Fit' I'm talking about is the current version available at retail.....a tiny, all-plastic item. Those 100+ MB/s we're referring to are the 'read' speeds; even these top-out at something like a max of 30-odd MB/s for the 'write' speeds. I am, however, thinking about purchasing a 512GB - half-terabyte - one of these for the old Dell lappie. These are currently going for around the GBP £60 mark, and will give me 512 GB of 'external' storage in a single port, leaving the remaining port free for a hub.....mouse, keyboard, etc.)

Mike.

Clarity wrote: Mon May 03, 2021 9:23 pm

Hi @TerryH

I am using this, "SanDisk Ultra USB 3.0", but the overall performance is horrible, at best, on the PC it is attached. My past findings is not good with few of my past USB-HDDs vastly outperforming my flash. So, I have limited my writing and use them mostly for reads; thus they exist primarily for data stores.

Maybe one day, I will spend the extra money for more expensive flash to see if I can attain the 100MB+ speeds I have heard about. Highest speeds couple of my USBs have shown is 13MB/sec

Just some personal findings of my USBs.

I ran the code for the 3 of Mike's scripts in a terminal, to keep the results. I'm happy with the write speed for this USB flash drive.

# dd if=/dev/zero of=testfile1 bs=256k status=progress oflag=sync count=4096
1064042496 bytes (1.1 GB, 1015 MiB) copied, 26 s, 40.9 MB/s
4096+0 records in
4096+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 26.8222 s, 40.0 MB/s

# dd if=/dev/zero of=testfile1 bs=512k status=progress oflag=sync count=2048
1067450368 bytes (1.1 GB, 1018 MiB) copied, 28 s, 38.1 MB/s
2048+0 records in
2048+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 28.1059 s, 38.2 MB/s

# dd if=/dev/zero of=testfile1 bs=1024k status=progress oflag=sync count=1024
1062207488 bytes (1.1 GB, 1013 MiB) copied, 25 s, 42.5 MB/s
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 25.4062 s, 42.3 MB/s

Made some code changes to the write256 script.

I got the terminal output to stay open by adding this to the code before -e
rxvt -hold ls

Not sure why the terminal got bigger, but it does stay open after script completes.
See image attached.

Also added 256k to ~ Drive write speed.....'
So it is now ~ Drive write speed 256k.....'
This makes the info on the terminal title clear on what it is testing.

Example for write 256K:

#!/bin/sh
#
# Write data block
#
HERE="$(dirname "$(readlink -f "$0")")"
#
if [ -f "$HERE/testfile" ]
then
	rm -rf $HERE/testfile
	sleep 1
	rxvt -title '        ~ Drive write speed 256k.....' -background '#ffff80' -geometry '70x2'rxvt -hold ls -e dd if=/dev/zero of=$HERE/testfile bs=256k status=progress oflag=sync count=4096
else
	rxvt -title '        ~ Drive write speed 256k.....' -background '#ffff80' -geometry '70x2'rxvt -hold ls -e dd if=/dev/zero of=$HERE/testfile bs=256k status=progress oflag=sync count=4096
fi

.

.
.
Made similar changes to all the other scripts.
Now each time you run one of the scripts.
The results stay displayed in the open terminal, until you close the terminal.

@bigpup :-

Uh-huh. O-kayyy.....

Right; well, after some testing, I've come to realise that there will have to be two releases of this.....for newer Pups, and older Pups.

The "-hold" flag doesn't work for older variants of rxvt....AT ALL. If you add your extra code in, the terminal window doesn't show up, and that rather defeats the whole point of this thing. I tried it in Sailor's Slacko 5.7.1, and.....no cigar. It's probably a more recent addition to the rxvt code-base, I would guess. Either that, or it was never compiled-in to older releases. (This works fine for Fossapup; I've yet to try it in older 64-bitzers.)

We may be able to find newer releases of Rxvt that will work in older Puppies.

-----------------------------------------------------------

As for the terminal going to full-size, that's simple to fix. The script is set to open Rxvt at 2 lines of 70 characters length. You're now asking it to display 4 lines of information, plus the prompt on the next line.....so it 'flips' to its default resolution instead. To get round this, just change the '70x2' argument to '80x6'. This will display the full info, and still keeps the Rxvt window fairly compact.

I've got to pop out for a little while, but I'll post modified versions later on.....including the extra bit of info in the title bar, to make it clear which test is currently being performed.

Mike.

Okay, gang.

DriveSpeed! v2

Only small modifications - basic functionality is untouched. I've included bigpup's code additions for 'holding the terminal open' when finished. This is combined with my own modification for making the window a couple or three lines 'deeper'.....just big enough to hold the final readout stuff, without rxvt 'flipping' to its default resolution instead.

'Block size' has also been added to the Rxvt title bar for each operation, to clarify what the current operation is doing.

-------------------------------------

The '-hold' flag actually works pretty well in my own kennels.

Fossapup64 - yes (by default)
Bionicpup64 - yes (by default)
Xenialpup64 - yes (by default)
BK's Quirky64 - yes (by default)
Xenialpup 7.5 - yes (by default)
Sailor Enceladus' Slacko 5.7.1 - yes (but with a 'workaround'). Basically, I just replaced 571's urxvt - rxvt is a sym-link to this - with the one from the later Slacko 6.3.0. 571 (based on 570, of course) has a urxvt from 2008. 630's urvxt is from 2014.....along with newer options.

Urxvt/rxvt replacement CAN work for our purposes with this utility.

------------------------------------

v2 is attached below. I'm not going to re-design the portable at the current time; as far as I'm concerned, it's working fine with sufficient options for full functionality. Only those who really enjoy "nitpicking" will continue to find fault and demand more options.

(For those of you who don't "code", making feature requests seems like the simplest thing in the world; folk tend to assume that anyone who creates packages - especially from 'scratch', like this one - must be fully conversant with, and expert at, all programming languages. When the individual in question is yours truly, that presents me with a mountain to climb; I've always been crap with languages (coding is like learning a whole new language), and the fact that I'm still at an early stage in my own journey means I simply don't yet possess the required skill-sets. And with the way things are at home this last year or two, I have a lot less time to devote to just 'playing' than I used to. So.....

.....you'll have to be satisfied with it "as-is"..! (The Puppy ethos positively encourages people to create stuff at whatever stage of development they've reached; there's no hard-and-fast rule that says you're not allowed to publish stuff until you've gained a certain degree of proficiency..! ))

It's completely optional as to whether anyone decides to make use of this. I don't think anyone's holding a gun to anyone else's head...

Mike.

Version 2 seems to work very well, thank you. It's not clear to me if you want comments, but I wonder if the test file should clear or delete when I quit.

Cheers
Yet another Mike

EDIT:

If it might be of some small interest (that is deletion here of the reproducible 1GB testfile) I added the file LoseTest (per image) which uses

rm ./DATA/testfile

and I click on LoseTest after successful execution of this natty innovation from mikewalsh.

Using Slacko 8.0 this morning, so gave the V2 a run to check the changes. So for me the hold doesn't work, window is still closing too quick to read. I booted into Slacko 7.0 to check it also. The hold does work in Slacko 7.0. Strange, they are the same version of rxvt from 2016, so no idea why it's not holding. Maybe somebody else can confirm this.

Edit: I went back to Slacko 8.0, checked bash version, it's newer (5.1.4) 2020. Seems the hold may have been deprecated in the newer version.

Even a simple code is not simple to produce

Slacko 8 is in beta stage and has bugs.
Latest one is Slacko64 8.1
Let it get to release version. before seeing how this program works in it.

Mike wrote: Tue May 04, 2021 3:47 pm

Version 2 seems to work very well, thank you. It's not clear to me if you want comments, but I wonder if the test file should clear or delete when I quit.

Cheers
Yet another Mike

@Mike :-

Glad to hear it's working for you. As with so many Linux utilities, this isn't supposed to be an "all-singing, all-dancing" utility; it follows the Linux mantra of doing ONE thing, yet attempting to do it as well as possible.

With regard to the 'testfile', the 'write' scripts have been written to check whether a previous test-file already exists; if one does exist, it's deleted prior to writing a new one for the current set of tests. Hope this clears that up!

(If you feel it would be better to remove it at shut-down, I'll look into doing that instead.)

Mike.

TerryH wrote: Tue May 04, 2021 4:32 pm

Using Slacko 8.0 this morning, so gave the V2 a run to check the changes. So for me the hold doesn't work, window is still closing too quick to read. I booted into Slacko 7.0 to check it also. The hold does work in Slacko 7.0. Strange, they are the same version of rxvt from 2016, so no idea why it's not holding. Maybe somebody else can confirm this.

Edit: I went back to Slacko 8.0, checked bash version, it's newer (5.1.4) 2020. Seems the hold may have been deprecated in the newer version.

@TerryH :-

Mm-hm. Yah, it does appear that certain of these additional flags are also dependent on other parts of Puppy's infrastructure, too. I guess I just struck lucky with the urxvt substitution in Slacko 571; doubtless, it won't necessarily work with other Pups in quite the same way.

Mike.

@mikewalsh Thank you very much for your response. However, it sings and dances very much to my personal taste and I like and understand how it works which why I used the word "reproducible" - but my largest Flash Sticks are 16GB and my fastest are 8GB and 4GB so I don't keep the savefile (which I could just delete manually, though I prefer to click my TestFile when I've finished ). So I thank you again - and I have no personal need for any more bells, whistles, notes or steps.
Alternatively, I could keep your original, as is, in some safe place and copy it temporarily to any drive to be tested - then delete your main directory after use (which was and is, I think, your recommended method).

Cheers
Mike

Mike wrote: Wed May 05, 2021 12:19 am

@mikewalsh Thank you very much for your response. However, it sings and dances very much to my personal taste and I like and understand how it works which why I used the word "reproducible" - but my largest Flash Sticks are 16GB and my fastest are 8GB and 4GB so I don't keep the savefile (which I could just delete manually, though I prefer to click my TestFile when I've finished ). So I thank you again - and I have no personal need for any more bells, whistles, notes or steps.
Alternatively, I could keep your original, as is, in some safe place and copy it temporarily to any drive to be tested - then delete your main directory after use (which was and is, I think, your recommended method).

Cheers
Mike

@Mike :-

That's how I use it myself; keep a 'default' copy in a safe location, then just copy it across to wherever I want to use it, run the tests, and delete the whole thing when finished with it. But there's no way of knowing how anybody else may choose to use it, which is why the write script checks for, and deletes any previous 'testfile' (if one exists) prior to commencing the writing of the current one. So I've left that in there.....just in case..!

Mike.

Firstly, this utility is so small the effort to remove if from the portable location is of no concen in my case. Because of this, it may be a candidate for inclusion in Puppy Utilities for speed-testing USB/SDcard/SSD units or for other storage media.

Next, there does not appear to be any reason to remove the USB changes before reuse of the USB. It does NOT change USB behavior or performance no matter if left or if erased before re-tests. In my case, the preference would be to use ONLY at complete tests at script exit versus use between tests.

Okay, guys'n'gals.

Now then; here is

DriveSpeed_v3

Following something of a re-write, and after much invaluable assistance from Fred & stemsee, this now features the addition of a partition selector/mount facility.

There is now no need to physically drag/move/copy the DriveSpeed portable directory onto the drive to be tested. As with all my portables; d/l; unzip; move to anywhere you want. Once it's there, it can stop there, as the partition selector scans for & gives you a list of all available partitions on your system. Select the drive/partition you want to test, then 'Mount' it.

The same choices of block size are still there; if you attempt to perform the 'read' test before the 'write' test, a warning pops-up to remind you the write test needs to be performed first (otherwise there is no 'testfile' to work with!)

The caveat still applies; remember to clear the cache buffers BETWEEN 'runs', otherwise you don't get an accurate reading.

Rather than using an rxvt window for the readout, progress is now displayed in a 'text window'.....in very much the same way that pBurn displays 'burn' speeds for optical discs.

Upon closing via the 'Quit' button, the 'testfile' is now automatically deleted from the target drive when you quit the utility.

-----------------------------------------------------

Still available as a 'portable', DriveSpeed! is now also available as a .pet package, too, for those who prefer the more traditional way of launching from a Menu entry. New pet & portable available from post #1.

Enjoy.

Mike.

mikewalsh,
You started this topic and have edit control, of the first post.

You need to attach v3 to the first post of this topic.

The first post is still only providing the v1, which you have now improved as v3.

If you read the first post.
The info on how to use this program, does not apply to version 3.
There is no info there even is a version 3.

It makes it easy for everyone, if the first post keeps updated, with the latest version and info.
The rest of the posts are just now info, on problems, and what was done, to improve or fix.

Version 3

Still working in EasyOS for the Raspberry Pi 4

Just an idea.
Does the writes really need to make a 1GB test file?
Seems to me 100MB file size would give info you need.
Anyway, some size smaller than 1GB.

Example:
I stopped the write 256K operation at around 100MB
The test file is 120MiB size.
256K read output:
.

.
.
Thanks for the improvements!!

@bigpup :-

There IS "method in the madness", as it happens.

As BK himself noted with EasyDD, you WILL notice the write speed performance of the drive slowing-down toward the end of the test.....as the drive's 'cache buffers' retain more and more data, and the controller is having to juggle data around further to send it where it's wanted.

Thus, you are only getting a true indication of the individual drive's "real-world" performance right at the end of the test. I DID experiment with this, to some degree; I noticed that the higher the block write count, the slower the data-transfer speeds became.....beyond a certain point, they stabilized & remained fairly steady. A filesize of 1 GB was chosen because it gave things a chance to even-out.

It's like so many things. Manufacturers are very fond of quoting benchmark performance figures for this or that item; but these are invariably under ideal 'test' conditions in a laboratory. Real-world usage is nothing like that.....and, in THIS respect, the utility does attempt to simulate "life" somewhat more closely.

Mike.

Right, gang.

Stemsee has performed a re-write of v3, which adds a couple more functions:-

• Adds a dismount function for the selected drive

• Allows the test to be aborted before the end

• Clears data from the /tmp-file and also the 'progress display' IF the test has been cut short

v4 also combines the progress window into the GUI itself (using, I believe, the "double-pane" function). I'm not certain whether you guys would prefer it this way or not, so.....I'm attaching just the modified v4 script to this post. Please un-zip it, and swap it over with the existing one; try it out, and let me know what you think.

(I still recommend running the test to completion, since you only get a true, "real-world" indication of your drive's performance as the cache buffers fill up and the write-speed correspondingly slows down. This is the condition the drive would be in during everyday use, so is, I feel, more informative.)

Mike.

Re: v4, I like it, being able to stop the test and the test results attached to the main GUI are good improvements.
I tend to agree with bigpup that 1Gb is too much in some situations, e.g. on a very slow USB stick I get around 800Kb/s and it takes ages to complete, now I just stop it after 100Mb written, knowing enough about how slow it is.

Fred

V4 is not working for me.

I get this when I start it.
.

.
This is in EasyOS for the Raspberry Pi 4, but version 3 worked OK in it.

@bigpup :-

Hmm. Try one thing, will you?

Stemsee's re-written this with the YAD "double-pane" construction. Try dragging the bottom edge of the window down?

What happens?

(It's entirely possible you need a newer version of YAD. Some of these features are only supported in very recent versions.)

Mike.

It is hard to get it to resize, but I did mange to drag it bigger.

That is the problem.

It is not opening in a big enough size window.

After I dragged the window bigger.
.

.
.
Not getting any output window when running tests.
So, you are probably correct about the version of yad being used.
Well, version 3 works OK.