jbartlett

Beta 5c pushed Added USB Tree Note that the speed displayed is the operating speed, not the maximum speed. A USB 3 device plugged into a USB 2 hub will operate at USB 2 speeds.

Beta 5b Modified logic for assigning drives to their controller port number & added additional diagnostic debug files if there are issues

The whole drive & controller detection logic was re-written from scratch so there's new gotchas involved. Previously, the program identified the controllers and then the ports attached to them, and lastly the drives attached to the ports. This proved to be troublesome with the server grade setups with multiple controllers on one, back planes, etc. that were really hard to get working since I didn't have access to such hardware to figure out how they're represented in the /sys/devices tree. Now it detects the drives working the other way around. It finds the drives, then the controllers it's attached to, and then the drive's port. I made some modifications to the port port detection & assignment and a whole metric crapton of logging tracing through the entire process. Please update to Beta 5b and rerun the scan. If you get another error, please recreate the debug file and email it.

Thank you. Your spinners have the expected "port_no" files for reference, I suspect that the app tried to identify the port numbers for your multiple USB drives. I added logic to exclude USB controllers when sorting the ports. Beta 5a Do not attempt to identify & sort by Port No for USB Controllers Do not list or benchmark USB drives when benchmarking all drives

Looks like it couldn't determine the port numbers of the drives on the controller. Can you please create a debug file for me and email it to [email protected]? The URL for creating the debug file: http://[IP]:18888/isolated/CreateDebugInfo.cfm Select the button for "Create debug file with Controller Info"

Beta 5 deployed Rewrote the drive & controller detection to scan for drives and then locate their controller & port info instead of the other way around Rewrote the system bus scan & tree display List all storage controllers first, then NVMe drives together, and then USB drives last under the USB controller they're attached to Display which USB Bus devices are on Added IOPING for drive latency and random/sequential seek tests, performed prior to a benchmark (info will be graphed in future update) Fixed "can not remove element" error during drive scan Added image & text defaults for USB drives Disable benchmarking or editing of USB drives Remove Info icon on USB controllers Do not submit USB drives to the HDDB If the controller Link & Max speed is the same, display one line instead of two with the label "Link & Maximum Link Speed"

Thank you! I just tested the individual drive benchmark and I couldn't reproduce. Give it a shot when I post the beta 5 release in a few after I finish hiding some code in progress so I can get a release out.

Does the controller report the link speed?

Sweet Mary Joseph Hossenfeffer!!

Noted about the red outline style. It's more of a proof of concept thing and it would resolve the layer overlap issue. I've also found and fixed (in beta 5) the index out of range issue mentioned above. I have a beta build of this beta (inception beta?) to test the new drive scanning logic. If you have drives that don't show up due such as using expander cards or multi-port controllers, this may resolve the issue. To test beta 5, change the repository for the Docker app to add ":beta" onto the end, the bold text as follows: jbartlett777/diskspeed:beta Don't forget to change it back after I officially release beta 5. NVMe & USB drives will show up after the other storage controllers. USB drives will have a static image.

That's odd that one drive out of many connected to the motherboard isn't being recognized. Only thing I can think of is that you have two controllers and one drive is plugged into the 2nd controller and that one isn't being picked up. I'm working on a new way to scan the drives which should pick up controllers better.

Yeah, that's new.

The others were reporting that error while scanning their hardware. This is the first I've seen it while doing a benchmark. Can you post a screen shot? You do not need to include the Java Stacktrace.

I think I'll be reworking how the text div overlay rotates. It's currently a free rotate but the issue is that it maintains the same shape while rotated so that's why the red box is so on rotated text layers - it has the height of the original frame but now also the width of the height of the frame rotated 90 degrees. It also has the issue with not being able to put the text to the top of the drive when rotated because the text layer is not as wide as the height is. I'll ponder changing it so that you can rotate 90 degrees left/right or 180 (up-side-down) and change the height/width of it being rotated 90 degrees so it stays the same height & width as the drive image. I've been studying the /sys tree for PCI buses, controllers, and drives and I'm going to write a test script to see if I can work at it the other way around. Right now, the program tries to identify the controllers and then figure out the ports on those controllers, then the drives attached to those ports. I can get a list of all attached drives from /sys/block and work up the system tree to find what port it's connected to and then which controller - and from there see what that PCI sclot that controller is plugged into or if it's part of another device.

I just pushed beta 4b which modifies the Debug Creation tool to include all files under 100 bytes with read permissions under /sys/devices/pci*

Beta 4a released. This version adds support to display a red box around drives that are currently showing activity. This utilizes the data from /var/local/emhttp/diskload.ini which seems to update every 5 seconds so the page checks it every 5 minutes. The red box doesn't display properly (it's too wide) around drives that have a rotated text layer, I'll address that later. I may opt to utilize the collectl command which can update more frequently and allow support for installation on non-UNRAID boxes but it's apt-get install routine takes in dialog that I'll need to figure a way around.

Sorry for the lack of updates for the past month, real life intervened. Beta 4 has been pushed. Those who couldn't even get past the controller/drive scanning should work now. For those who's SAS controllers aren't detecting, still investigating. But drives attached to them should fall into the "Unknown Controller" section so you can still benchmark them. Fixed drive/controller scanning issue when scanning up the bus tree and not finding a drive Do not display the "Unknown Controller" if only the UNRAID Flash drive is under it Do not benchmark the UNRAID Flash drive Mitigated a race condition where multiple threads might try to write to the same file at the same time during a benchmark Flag the UNRAID Flash drive as nonsubmittable to the HDDB Flag drives with invalid characters in their vendor/model/rev as nonsubmittable to the HDDB Group NVMe drives together after non-NVMe drives

Is this repeatable? Can you verify that Privileged is enabled in the Docker settings? If it is repeatable & privileged is enabled, alter this URL to match the IP of your unraid system and open. Create a debug file through this URL and email it to [email protected] http://[ip]:[port]/isolated/CreateDebugInfo.cfm

I'm investigating...

Update your Docker and try the benchmark again and let me know if it worked - you don't need to purge again. I moved the temp files from the exported "DiskSpeed" directory to one internal inside the Docker (which gets cleaned up whenever you update the Docker) but missed a path reference. It should have only happened if you previously aborted a benchmark prior to updating the Docker app.

What the app does is to start a balls-to-the-wall read of each drive using dd (to null) with the progress & cache bypass switches as background tasks running simultaneously. After 15 seconds, it kills the pids of the background processes and then analyzes the log files. To the OS, it should look like x number of applications requesting disk data. This is different from unRAID because unRAID will read one block from each drive, check, read the next block, check that block, repeat - the drives should naturally balance out the reads as unRAID is (likely) self-throttling. I'm not sure how I can work around this.

Is this reproduceable? I can't see how this would have happened unless there was a race condition where two processes were deleting the files at the same time.

How many CPU threads do you have available to unRAID (& Docker)? As in, not pinned to any VM or the like?

Beta 3a: Remove debug line which had drives testing for only 5 seconds instead of the intended 15. This may have resulted in slightly less accurate speed scores but should still be in an acceptable margin of error.