jbartlett

Targeted cooling. USB powered fan resting on felt wraps and wedged into the ledge, cable running up and out the water cooling ports to the USB ports. Intended to blow air on the SAS chipset & NVMe drives.

Beta 3A NOTE: Ryzen Threadripper (X399 Chipsets) with IOMMU enabled will not run this version successfully. I am diagnosing the issue. If you have missing controllers or missing drives, please click on "Create Debug File" link at the bottom of the DiskSpeed home page to create a debug file with controller information included. Do not submit unRAID diagnostic files unless asked. Email the debug file to [email protected] Change Log Single thread the process which analyzes & cleans up the benchmarks to prevent against a race condition where two threads try to process it at the same time Reworked how NVMe drives are detected Scan all PCI root ports for controllers Modified IOMMU detection Handle drives rebranded with Apple Drive model cleanup for ADATA, Corsair, LITEONIT If the first word of the Model matches the Vendor, remove it If the drive is not found in the Hard Drive Database, add a link to allow the Vendor to be modified. Move benchmark processing files to Docker contained temp file to allow for auto-cleanup during docker updates Detect if a drive was added to the Host after the Docker started Do not submit benchmark results if the drive was tested at fewer than every 10% Do not submit benchmark results if bandwidth capping was detected Do not include labels for drives never benchmarked on the main page benchmark graph Expand the debug file creation to include certain PCI device information to help identify controllers not yet supported Don't display benchmark average if there's only one benchmark done Fix text overlay style error on drive images, hopefully drives will now match the editor Change the label of the "Purge Everything" button to make it more clear and add a confirmation dialog

That's fascinating. It does look like that but I haven't seen any controller not load-share the reads like that. It should have kept scanning fewer drives though until it gets under 90% of the max throughput detected or it runs out of drives. Here's a controller test on my test rig. It gives all the drives equal time on the first pass which maxed out the bandwidth even though it meant capping the read speeds of each drive.

Wait until the next beta and then click on the "Create Debug File" link at the bottom of the drives. I'm finalizing testing on it now. I'll post a change log when it's ready.

If you mean that it didn't detect the drives, the next beta will partially resolve that.

I've been shying away from all the Seagate DM drives except for NAS backup systems. They all seem to spin at 5,980 RPM and none of the drives I've tested has a smooth graph from start to end.

Logitech Brio.

The different camera views are all powered by the Logitech Brio set to 4K output and broadcasting at 1080p.

Thankfully!

New beta delayed by kittens. Picked up new fosters last Tuesday when they were three days old. Foster Kitten Cam They're time consuming. What I'm currently working on with the next beta: I've added support for the debug file to upload a full directory tree of /sys/devices/pci* both in text form (tree command) and a copy of any file with the words vendor, model, size, portno, firmware, serial, rev, and phy- in the file name with their directory tree duplicated. This will help me identify/gather information on drive controllers the app currently doesn't identify. Added an "Unknown Controller" section that all orphan drives are attached to to enable information & benchmarking Adding USB Hubs as a controller and the drives attached to them Adding the means to enter in the drive Vendor when it is misidentified, incorrect (such as rebranded), or not provided. Adding support to detect if the drive's bandwidth is being exceeded and not allow those benchmarks to be uploaded to the HDDB.

There's no way I can guide writes to a spot on a drive by creating a file and nobody will trust a read/write test (read the block, write it back). Basically, I wouldn't touch that, code wise or with a different application.

ColdFusion/Lucee has scheduling/cron support, should be easily enough to schedule tests.

Note that the SpeedGap detection is on by default. It shows up during the test as "Speed Gap of 128MB (max allowed is 45MB), retrying (1)". The number at the end is how many times it re-read the same block and it'll increase the max-allowed number by 5MB each iteration. The option to disable the SpeedGap logic was added because I had one drive on my main server that had such erratic reads that it took forever to test and would test each block dozens of times until the allowed gap finally grew large enough to allow it to continue.

Was there any "SpeedGap" detected? That's the alert if it detects disk activity while it was reading the drive for 15 seconds if there is a gap of 45MB/sec difference between the slowest speed & fastest speed. If in doubt, shut down any VM & Dockers that may be accessing the drives and retest. You've got two widely different tests so that hints that something else was hitting the drive hard while you were testing it.

The old script loops over /sys/block to get all of the drives. The next version will have an "Unknown Controller" section where drives that weren't detected through a controller will be listed so they can be benchmarked - and it'll include new support for the debug file to help identify controllers.

It'll also add an "Unknown Controller" and put any orphan drives under it for controllers my code can't currently identify.

I've added code for the next beta that'll create a debug archive with extra information for helping to code for undetected controllers. Once I finish adding code that'll detect drives that have their throughput constrained by bandwidth limitations (such as a fast drive on a slow port) to disable uploading benchmarks for it, I'll be ready to push the next beta. The beta version that's out will only scan under /sys/devices/pci0000:00 so some controllers are being missed entirely, notably systems with IOMMU enabled. The next beta will scan /sys/devices/pci*

The Docker settings will display how much space is being utilized by your containers and you can increase it from there. The Docker currently needs 727 MB of space to install.

That's on my To Do list to optimize memory utilization. The default settings will use a max of 512MB of RAM which is stated in the initial post. I'm still adding features, it's too soon to optimize things for a beta but I'll check to see how much room it's using now and shrink it a bit if there's a lot of headroom.

Confirmed. Had two browser windows open to the same server, issues a reboot with one, the other started giving the bad token after the reboot until the page was refreshed.

They're already "live" with VM's and Plex cache so I can't. However, my syslog is full of the following: Apr 14 03:40:16 NAS root: error: /plugins/unassigned.devices/UnassignedDevices.php: wrong csrf_token nas-diagnostics-20180414-0338.zip

Ugh. I'm typically pretty fastidious about keeping them updated. Been a crap couple of months.

Foster Kitten Cam actually. I foster for Purrfect Pals which is located in Arlington just north of you. I'm just a stone's throw from the southern border of Mill Creek. Fostered 59 sets since 2008, mostly kittens or queen's and their litter and a few adults. Waiting for the call for #60. Currently, my foster kitten cam is showing highlight clips made of my fosters over the years, you can watch for a week and not see any duplicates. I'm known as "Foster Dad John" over there, or FDJ for short. https://gaming.youtube.com/watch?v=gnsZwg09u6A

Auto-mounting a disk outside the array via UD and then adding it to an array without disabling the auto-mount leaves the drive mounted though UD and reported by unraid as having no file system in the array with a duplicate UUID. nasbackup-diagnostics-20180412-1539.zip

I just noticed that I’m getting a lot of PCI errors with the Threadripper motherboard, forgot to implement a fix put in my test rig with it so lots of noise in the syslog. I’ve got my NVMe devices set up so I won’t be able to test it again.