jbartlett

Can you create a regular debug file and email it to me? Link and info is on the bottom of the DiskSpeed app screen. This way I can look at what the system is reporting for the drive.

It's odd that the drive reported different speeds. The Samsung PM1733 has a max read speed of 6,400 MB/s based on this spec video but your speeds are much slower for the SSD. Only recommendation I have is to verify that you have it connected to a PCIe Gen 4 interface. It kinda looks like a gen 3 speed.

Apologies, I misread your question and my brain flipped the numbers. If you don't mind, let's try two tests against the drive. The first test duplicates how DiskSpeed performs a benchmark at the start. In these examples, I'm testing against /dev/sdd - change the drive reference to reflect your PM1733. This first test you will need to break out to stop. Test 1: dd if=/dev/sdd of=/dev/null bs=1310720 skip=0 iflag=direct conv=noerror status=progress Now let's do the same but against a file. Locate a large file and change the if= reference to point to it. Test 2: dd if=/mnt/disks/SSD_327E/Cam1/OS.qcow2 of=/dev/null bs=1310720 skip=0 iflag=direct conv=noerror status=progress Test 2 is how I plan to have version 3 of DiskSpeed to perform a benchmark. What are the transfer speeds?

NVME & SSD drives only provide normal benchmarks with the current DiskSpeed version if the drive has been written entirely (such as a single preclear write pass) or filled up. If a benchmark is read on a brand new SSD, it'll report reads off the chart because the drive knows if that spot has ever been written to previously and if not, returns null's without accessing the memory. The next version will have a new method of testing the read/write speeds of solid state mediums by either finding and reading a large file or writing & reading back a large file. When the next version will be released is anyone's guess. I'm a married man now, my development time is thus nipped.

Can you share the error screen? From the list of actions being taken to the error message - no need to include the long java stack, just the error message and where it occurred.

Interesting. You might be right. I'll be keeping an eye on it and will monitor the syslog.

Just had something odd happen. I needed to look up the <progress> HTML tag for another project and I ran my DiskSpeed app and hit a benchmark on a random drive and did an inspect on the HTML of the progress tag to get it. I could have just googled it but ah, I digress. I noticed that the speed was flat lined at 141MB/sec. I let it finish and it started to go down towards the very end but was flat up until that point. I ran subsequent tests and they all showed the same thing - a max bandwidth of 141MB/sec while all other drives on the same controller (motherboard) behaved normal. I did a power off reboot and now everything is back to normal. I didn't think to save off the syslog so no checking that. Anyone else have had this happen to them?

Wondering what you mean by "feel slow". But those are good speeds. Try running a controller benchmark to see if a controller isn't able to handle all the drives active at the same time. I'll get a read speed from each drive one after the other and again all at the same time and compare the two. From what I see, you're using an onboard controller with three drives out of a possible six. It looks like it should be able to handle it fine. You can also try running a disk benchmark at with a 1% interval scan (101 scan points vs the default 11) which might help locate questionable areas. The next major release of DiskSpeed will add support for full surface level testing but I don't have a timeline for that release. I'm currently slammed at my job and I haven't had much time of late for hobby programming.

I think I follow what you're saying. The parity rebuild should function the same as forcing a write on each sector and then verifying that write - but you'll be at a greater risk of a party rebuild failing since all sectors must report OK.

I did that with mine. But in your case, I'd copy (not move) files onto it and then do a binary/crc compare on the files to ensure they're identical. Beyond Compare by Scooter Software can help with this. Then once a match is verified, remove the source.

I just discovered the reason behind DiskSpeed's controller benchmark low scores. The dd command progress MB/sec speed indicator is an overall average, not the speed over the last second as I had assumed. dd includes the spinup delay in it's speed average calculations. The following command against my Parity drive spun up shows top speed right away but much slower speeds that slowly climb if the drive was spun down. Take note if you use dd to test your workaround. dd if=/dev/sdh of=/dev/null bs=1310720 skip=0 iflag=direct status=progress conv=noerror

This is likely two different issues that present in the same way. I spun down my drives connected to the MB controller and performed a DiskSpeed controller benchmark and was able to duplicate.

Your USB device is annoying. 😁 I added an existence check for that variable and looked for other potential misses and repushed version 2.9.3

This issue isn't due to UNRAID OS. For anyone getting this issue, spin up your drives first before running a controller benchmark. The cause is that my spin-up logic isn't working. The first second of the 15 seconds if data read is discarded to account for any drive head relocation but the spin up times is causing at least one second of 0 MB/sec read which is hurting the average. This issue isn't evident on the individual drive benchmarks because it performs seek & latency tests first so the drive is spun up before it gets to the benchmark.

Good news: It's not your system! I spun down my drives and ran a controller benchmark and I got the same results. The drive benchmark performs a couple seek tests & a latency test on the drive prior to benchmarking so it's pretty much assured to have the drives spun up when it actually starts reading the drive via the dd command. The controller benchmark doesn't do those tests prior. I need to revisit the spin-up logic.

All would be telling. Notably if the drives on one controller is higher than drives on another. In theory, they should all be roughly the same. If it looks like they are, just a number. It should be given in milliseconds or 1000=1 second. The dd command outputs a status every second so if it takes longer than I accounted for, I may need to increase the number of seconds to drop from the start.

Can you provide that information?

The average speed logic discards the first read which includes any potential spinup / drive head placement. It might not be dropping enough in your case. Does your SMART data include spin up time?

Clicking on the "Benchmark Drives" button on the home page (click on the "DiskSpeed" header) allows you to benchmark all controllers at the same time with controller testing each drive attached to it in sequence.

The error in the USB Bus tree stopped the rest of the page from displaying which prevented you from seeing the Benchmark All button. I pushed version 2.9.3 which checks for the existence of the idProduct variable and sets it if not created by the USB device.

If the file names are unique, creating a copy of the files in a single directory for both versions and then using Beyond Compare to compare the directory, missing files will be easy to spot.

My DiskSpeed app uses the dd utility to read the drive for 15 seconds for each drive on the controller in succession, then the same command against each drive all at once. To get slower speeds during single-drive reads vs multiple drive concurrent reads is weird. I'd have to say that it's not my app but my app is showing the issue at hand.

Deployed version 2.9.2 which will ignore virtual USB hubs

Can you show me how you have the USBIP module vhci_hcd set up so I can duplicate the issue as you have it configured?