jbartlett

One of my 6TB WD Red Pro's clicks every 30'ish minutes

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.

It does work with UNRAID 6.5 but something with your configuration is unexpected. I'm working on a new way to identify drives & their controller but real life keeps getting in the way. This isn't the correct place to post issues with the docker app though.

I have a Win10 box running on an Atom fanless system which was being used only for USB over IP devices. It suited that task quite well even with web cams but for anything else, it took forever. Windows Update was a nightly process. I tried getting different unix installs on it but I've never been successful with any of them (primarily Debian). I built an unRAID box for a friend using the same MB and it's suited that task quite well as a NAS with some Sync docker & plugins.

To expand on what was mentioned above, never use standard ports on any home server, exposed or not, if you can help it.

Looks like they finally released a new BIOS a week ago, going from F2 to F10. I'll be trying that too.

Never heard of that. I'll give it a try once some long running tasks have finally finished.

There's too many stuff grouped with it [1022:1452] 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe Dummy Host Bridge [1022:1453] 00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge [1022:1453] 00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 00h-0fh) PCIe GPP Bridge [1022:43ba] 01:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset USB 3.1 xHCI Controller (rev 02) [1022:43b6] 01:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset SATA Controller (rev 02) [1022:43b1] 01:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] X399 Series Chipset PCIe Bridge (rev 02) [1022:43b4] 02:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1022:43b4] 02:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1022:43b4] 02:02.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1022:43b4] 02:03.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [1022:43b4] 02:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 300 Series Chipset PCIe Port (rev 02) [8086:1539] 04:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) [8086:24fd] 05:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78) [8086:1539] 06:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection (rev 03) [1000:0072] 07:00.0 Serial Attached SCSI controller: LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 03) [144d:a804] 08:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961

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.

What browser are you using? Your rotated text labels aren't centered right and but the red box is properly outlined? This is what I see in Firefox

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.

It does not.

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...

This version should work ok in 6.5 and future versions unless a fundamental change happens with the unRAID OS but it is not actively being maintained. Please see my signature for the current DiskSpeed app.

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.