DriveSpeed! (v4) - a 'dd'-based drive speed tester - .pet & 'portable'

[fredx181]

Yes probably too old yad version, that has the --paned option not supported.

[mikewalsh]

@bigpup :-

Odd. It opens full-size for me; Fred and stemsee don't appear to have any issues with it, either.

If you hover your mouse between the bottom row of buttons, and the row of 'Read' buttons, does your cursor change to a kind of double-ended arrow thing? That's about where the two panes are joined together. Can you drag it down or up from there?

In a terminal, enter this:-

Code: Select all

yad --version

.....and hit 'Enter'. What result d'you get?

Mike.

[bigpup]

# yad --version
6.0 (GTK+ 3.24.14)
#

[bigpup]

If you hover your mouse between the bottom row of buttons, and the row of 'Read' buttons, does your cursor change to a kind of double-ended arrow thing? That's about where the two panes are joined together. Can you drag it down or up from there?

Yes, I can do this.
If I do this. I now see result info when running tests.
.
.

Screenshot(7).jpg (56.18 KiB) Viewed 1562 times

[fredx181]

# yad --version
6.0 (GTK+ 3.24.14)
#

Ah, gtk3 yad version, strange that it doesn't show properly with the --paned option (as it does okay with yad gtk2, which I have)

[mikewalsh]

News to me, I'll admit. I wasn't even aware there were two variants of YAD....

@fredx181 :- Fred, if Barry's built EasyOS to use a GTK+ 3 version of YAD, would there be any point trying with the GTK+ 2.0 one? It would probably break more than it would fix, I'm thinking.

Mike.

[stemsee]

I removed the --splitter option because on fatdog it was all open for text info. When i removed the splitter option (splitter position between the two panes) it gave a suitable display of both! I have never managed to get a good splitter positioning ... I usually cheat it by adding buttons etc which force a certain display! Maybe bigpups' yad is a drop in with the old config file!

[fredx181]

News to me, I'll admit. I wasn't even aware there were two variants of YAD....

@fredx181 :- Fred, if Barry's built EasyOS to use a GTK+ 3 version of YAD, would there be any point trying with the GTK+ 2.0 one? It would probably break more than it would fix, I'm thinking.

Mike.

Hi Mike, I'm not sure to understand exactly what you mean about breaking.
The gtk3 yad needs a different approach in some cases (I tested), for this script as made by stemsee the --width and --height needs to be specified at the last yad command (with the --paned option), attached DriveSpeed.tar.gz with that change for gtk3 yad.

DriveSpeed.tar.gz

(1.45 KiB) Downloaded 80 times

[greengeek]

Drive speed utilities are handy for determining which laptop ports are usb1, or usb2 or usb3

It is handy to move a test stick around from port to port to identify your fastest port - and put your boot stick there for faster booting.

[mikewalsh]

Okay, guys'n'gals.

This is pretty much the final release - DriveSpeed! v4

This is as the v4 test script I published earlier:-

The progress window is now part of the GUI, added using the "double-pane" functionality of modern YAD. If you want the progress window larger, showing more lines, simply drag the bottom of the window down a bit. (You'll see a wee row of dots in the screeny, above the progress window and below the 'Read 512k' button; this is where the two 'panes' join.)

Select your drive partition, and mount it. Select the write operation of your choice; either let it run to completion (this gives the most accurate picture of your drive's performance).....or, if you want to cut it short, Stop Test -> Clr DATA. Then run the read test; again, choose your block size.

If you want to cut the second test short and Quit, don't just Stop Test -> Quit; it'll hang if you do. Stop Test -> Clr DATA -> Quit is the way it's meant to work.

The testfile is deleted at shutdown, as previously.

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

Downloads in post #1. Hope it's useful.

Mike.

[bigpup]

News to me, I'll admit. I wasn't even aware there were two variants of YAD....

@fredx181 :- Fred, if Barry's built EasyOS to use a GTK+ 3 version of YAD, would there be any point trying with the GTK+ 2.0 one? It would probably break more than it would fix, I'm thinking.

Mike.

Hi Mike, I'm not sure to understand exactly what you mean about breaking.
The gtk3 yad needs a different approach in some cases (I tested), for this script as made by stemsee the --width and --height needs to be specified at the last yad command (with the --paned option), attached DriveSpeed.tar.gz with that change for gtk3 yad.
DriveSpeed.tar.gz

Used this modified DriveSpeed
It works for me as it is suppose to.
so, this seems to fix my issues with YAD GTK+ 3 version.

Tried the version 4 from the first post.
It still has the problems I reported earlier.

Thanks for the work to improve!!

This is software coding!
The original coder (mikewalsh)
The pain in the as# tester (me)
That other coder, that jumped in to help (fredx181)
The pain in the as# tester (me)
The finished code accepted by the original coder (mikewalsh)
final release!

[fredx181]

The pain in the as# tester (me)

Now let me be the pain in the as# tester
I hate to say it, but I wouldn't recommend v4, see also viewtopic.php?p=24669#p24669 and further.
A few times when I clicked QUIT and forgot to "Clear Data" the window freeze and had to force kill it, with the result that still a yad process was leftover, eating loads of CPU (so needed to find the pid of that process and kill it).
EDIT: This is the leftover yad process:

Code: Select all

root      7240 76.4  0.9  51880 19008 ?        R    10:09   1:27 yad --plug=7233 --tabnum=2 --listen --tail --editable --text-info

Another thing (goes for v3 and v4), see here: viewtopic.php?p=24718#p24718

Fred

[bigpup]

mikewalsh stop slapping your forehead
Are we having fun yet?

[mikewalsh]

I guess this will teach me two things, in future.

• Much though I appreciate the interest & assistance of others - I have nothing but respect for both Fred and stemsee, as well as many others in our community - I really shouldn't just accept large chunks of code that I honestly don't understand! (My comprehension level simply isn't there, yet...)

• Despite other people always clamouring for more features/more 'bells & whistles'/supposedly better ways of "doing stuff", sometimes - just sometimes - small & simple really does work better.

My personal view (and I know at least one other person who whole-heartedly agrees with me) is that v2, using bigpup's addition to help hold the terminal open, and my increasing the number of lines Rxvt was displaying so all the final readout shows, is actually the best option here. It's simple & pretty basic, yes.....but everything that's needed is there. And it works! (As the TV advert runs, 'it does what it says on the tin'...) Although I've published the other versions, it's the one I'm still using myself.

So I'm inclined to recommend a slightly 'tweaked' portable release of v2.

• Keep a 'safe' copy somewhere

• Copy it across to the drive you want to test

• Run the tests

• Delete the entire thing when you're done

('Tweaked' v2 re-added to the attachments in post #1.)

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

I'm well aware that my enthusiasm for 'portable' stuff is NOT what most members of our community are used to. Many actively prefer launching an app installed to a fixed location, from a menu entry, then the app handling what's needed from there....because it's what they've always known. It's the traditional way this stuff has ALWAYS been handled. And the older you get, the harder change comes.... I know this, for a fact, yet change is the one thing that's constant in the universe!

A few here share my 'predilection', so I'm not entirely alone. My own view is that change is good for any community. There will always be a place for the traditional operations, but I believe there IS room for the two to peacefully co-exist alongside each other.

Enough of my ramblings!

Mike.

[bigpup]

BLtSmWXCAAAfHK4.jpg (64.16 KiB) Viewed 1753 times

[mikewalsh]

@bigpup :-

^^^Lololol!!!

Spot ON, mate. That's it to a tee.....

Mike.

[fredx181]

Hi Mike,

No one's lost overboard!
I can see that your position is difficult, with less experience in coding than me or stemsee.
I agree that simple can be better in most cases.
Anyway, when it's more complicated it has more chance of containing bugs and should take more time to test things.
On the other hand, I see this little project as still rather simple, e.g. some things such as partition chooser included, not a real luxury I'd say.
Maybe you shared here too hasty ? (specially v4).
The other thread I see as sort of playground to share ideas or talk about, but this thread is different, where you share a program.

Anyway, I've been testing a lot v4 and made some fixes and improvements, should be OK now, see viewtopic.php?p=24737#p24737, feel free to do anything or nothing with it.
EDIT: Still in progress, see further replies EDIT2: New script: viewtopic.php?p=24750#p24750

Fred

[mikewalsh]

Morning, gang.

Having learnt a few new tricks since originally publishing this thread, I'm pleased to be able to offer DriveSpeed_v2.2-portable.....a re-working of my own favourite 'older' version.

Selection of write block size, read block size, and test-file size are all now accomplished via drop-down menus, and are pre-selected before carrying out the tests....the output of the drop-downs are written to wee text files in /tmp. These are 'grep'ed for the requisite information at the appropriate point during execution of the various scripts, and are deleted again at close of the utility.

She now uses block sizes of 512kb, 1Mb, 2Mb, and 4Mb. For the 'test-file', you can choose from 1Gb, 2Gb or 4Gb.....this was one 'improvement' @Clarity asked for, earlier in the thread. The choice was quite simple; for those of us running older, weaker hardware, the operations will necessarily run slower & take longer to complete, so a smaller 'test-file' is more appropriate. For those of us with fairly powerful hardware, and much larger/faster drives - plenty of us now run SSDs - a larger 'test-file' will help to give us more consistent results.

I've also re-designed the GUI a bit, and have numbered certain of the buttons to make it somewhat clearer as to which order they should be used in.

Probably not strictly necessary, I'll own, but 'twas all good fun, and good practice for me, too! The new version is attached to post #1 of the thread. Hope y'all like it. Enjoy!

Mike.

[Snail]

Hi Mike,

I have just started playing with your V4 drive speed tester. Thank you very much for this.

I'm running V4 installed as a Pet on Fossapup-9.5 with Pupmode=5 on a USB stick.

I tested sda2, which is the Windows C drive on HDD. It's a Seagate-ST500NM0011-500GB on SATA 3.0. I got the following results:

Read speed not significantly affected by blocksize at about 153MB/s.

Write speeds for 256k, 512k and 1M block sizes were approximately 7, 13 and 26 MB/s respectively.

By comparison, this site https://hdd.userbenchmark.com/Compare/S ... /m2942vs10 gives the following speeds:
Average sequential read - 118MB/s
Average sequential write - 114MB/s
4k read - 0.85MB/s
4k write - 1.99MB/s
Average sequential mixed I/O - 63MB/s
Average 4k random mixed I/O - 0.95MB/s
Average sustained write - 109MB/s

A quite bewildering range of numbers! Can anyone comment on how to interpret them please? Is my fairly old HDD still performing adequately?

I also tried DriveSpeed on the USB stick I'm running Fossapup from.

PupSysInfo gives:
VendorID=13fe ProductID=4200 Rev=01.00
Manufacturer=UFD 2.0
Product=Silicon-Power16G
SerialNumber=P1601370070B65D2ABBFA458

It's plugged into a USB 3.0 port.

EDIT No, it's only a USB2. Although the motherboard, has plenty of both ver 2 and ver 3 USB slots, for some reason , the two easily accessible ports on the front panel are only USB2. This computer is commercially built but clearly only by some garage- entrepreneur, not a major company. So maybe the internal cable connecting is a bit off. I'll have to check.

Again the read speeds are not much affected by blocksize at 26MB/s.

Write speeds for 256k, 512k and 1M block sizes were approximately 8, 10.5 and 12 MB/s respectively.

I did not originally appreciate that the read and write buttons were labelled by block size, not data transfer amount! all tests write 1GB of data. This might have been interesting had I tested my oldest, 100MB stick. (It cost $100 for 100MB back then).

[greengeek]

I think I have scanned the thread thoroughly - but have a question:
Do these utilities take into account the situation where a "data copy" transfers data only within memory - waiting for later approval to do a "disk-write" (depending on pupmode and various timeouts etc).
Cheers!

[mikewalsh]

@greengeek :-

I think I have scanned the thread thoroughly - but have a question:
Do these utilities take into account the situation where a "data copy" transfers data only within memory - waiting for later approval to do a "disk-write" (depending on pupmode and various timeouts etc).
Cheers!

Ian:-

I'm not quite sure what you're getting at. The earlier versions were always intended to be 'portable' & 'disposable'.....at least, that's the way I envisaged them being used. The last release, a modified version of v2, had quite a number of improvements added.........the ability to pre-select read & write block sizes, along with the ability to choose from a small selection of different 'test-file' sizes, too.

• Keep a 'master' copy of it somewhere safe

• Whenever you want to speed-test any drive, simply drag a copy onto the root of that drive

• Use it straightaway; select the write-test 'block' size, then the read-test 'block' size, followed by the size of the required test-file

• Run the write-speed test first. Then clear the drive's internal 'buffers' (this keeps the readings more accurate). Then run the read-speed test. The important buttons are all numbered in sequence, to help guide the user through the process

• Finally, just delete the whole thing when you're finished with it (it's only a couple of hundred kb in size)

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

I'm not at all sure about versions 3/4..! Fred and stemsee got hold of it, started playing around with all sorts of ideas, extras, additional refinements to the GUI.....the 'project' rather got away from me, and I kinda lost track of what the hell the pair of 'em were doing with my creation..!

I believe these two versions were designed to be installed as a normal .pet - some people had asked for that - and to search around the system to find drives. Some people appear to like having lots & lots of options and technical refinements; me, I try to keep stuff as simple and easy-to-use as possible. I attempt to put myself in the user's shoes; just because I know and understand how something works, it's pointless releasing a package that nobody else understands how to use.....is it?

V3/4 may well need to take your original concerns into account. My originals were never intended to leave data hanging around in the file-system; you drag it where you want, run the tests immediately then just as quickly delete the whole thing.

Unless I've got hold of the wrong end of the stick...?

Mike.

[greengeek]

I'm not quite sure what you're getting at.

I didnt explain it well - what I meant is that on some of my Puppy installs - if I copy a large file onto a usb drive the copy will start, then appears to terminate successfully, but later on I realise that a large portion of that copy is still sitting in ram waiting to be flushed out onto the usb drive. Usually I realise this when I go to shut down and Puppy will not let me immediately unmount the drive. It pauses for quite some time until the ram (or buffer?) flushing is complete - then it will finish the unmount.

At one time I was using a 100MB Puppy iso as my data block to be copied to a drive (for the purposes of timing the speed) but I realised the results were variable dependent on whether the data transfer was being done in ram, or ACTUALLY writing to the drive (so some results were almost instantaneous and others were 10 seconds or so).

Just wondered if you had encountered and overcome similar things. (But probably this behaviour was dependent on my setup at that time: ie pupmode etc)