Leaderboard

Just a couple years ago I was reading a fascinating article about the return of 3Dfx, and their new graphics card that was beating up on AMD and nVIDIA's latest and greatest. I was in shock, I thought 3Dfx was long dead, and here they were with a surprise return out of nowhere, and were now in the performance lead. I kept thinking this was impossible... but I kept believing what I was reading, with pure fascination and joy... until I got to the Minesweeper FPS charts!!! I had completely forgotten it was April 1st. The experience forever changed me, to the point I can't wait for April 2nd to come and all the fake news to end. I now have a really hard time believing anything I read on the 1st of April. So, being April Fools and all, I had to get the big prank out of the way earlier before sharing this news. Otherwise I was going to wait until tomorrow to share this development, in case someone thought that this was a prank. This one is no joke. It seems that my unRAID stability issues are resolved by disabling "Global C-state Control". In the ASRock BIOS you can find it under: Advanced -> AMD CBS -> Zen Common Options -> Global C-state Control. I've read elsewhere that on other motherboards you should still find it in the Zen Common Options section, so look for it there in your own BIOS. Here are my last 8 tests, the last 4 of which I've only been toggling just this one setting: Enabled = <4 hours, crash Disabled = 55+ hours, System auto-shutdown when UPS battery drained during power outage. Enabled = <90 minutes, crash Disabled = 10+ hours, got bored and rebooted Enabled = <30 minutes, crash Disabled = 13+ hours, got bored and rebooted Enabled = <3.5 hours, crash Disabled = 6+ hours, decided I was done testing Most importantly, the server has never crashed with Global C-state Control disabled. The only real downside I've found so far is that idle wattage has definitely increased. With Global C-State Control enabled, I was typically seeing idle wattage of 73w, with it disabled it's now idling at 87w. That's a big 14w jump for an idle CPU. (Note, I just tested this again with my 24-drive controller finally installed and all hard drives spun up. Wattage went from 151w with it enabled, to 158w with it disabled, so a more palatable 7w difference. Not sure why the better result.) I've also found that, with it enabled, I can get the server to crash pretty quickly simply by ignoring the server (no, not emotionally, silly). It seems that even bringing up the web page and monitoring the Dashboard creates just enough load to make it take longer to crash, much as running a VM gives the server more work and delays a crash, often by days. If I completely ignore the server (by closing the web pages so they aren't updating in the background), the server typically crashes within an hour. Probably because the server is going into lower power states much more readily with nothing to do. Since the problem really does seem to be with power management and the processor entering very low power states, I've been trying to figure out which C-state exactly might be causing the problem. I've done some research and matched it up with my testing, and here's what I've got so far: According to AMD, if "Cool'N'Quiet is disabled, then low power C-states will also be disabled. Not sure if this is true, nor exactly which C-states get disabled, but disabling Cool'N'Quiet did not resolve the issue. Disabling "Deep Sleep" (which is a variation on C3, not C4 like I thought earlier) also did not resolve the issue. Disabling "C6 Mode" (a.k.a. "Deep Power Down" mode) also did not resolve the issue. Only disabling "Global C-state Control" resolved the issue. I haven't been able to find any answers on exactly what this setting is doing. I can only assume it is completely disabling all C-states, from C1-C6 (or higher, haven't been able to figure out what C-states Ryzen supports), leaving the CPU always operating in C0. From what I've read, it seems that the processor has to increment through each C-state to reach the next, i.e. C1 -> C2 -> C3 -> C4 -> C6. You can only get to C6 from C4, and only to C4 from C3. Since C3 is also known as "Deep Sleep", when I disabled Deep Sleep in my BIOS, I think that means I effectively disabled C3, C4 and C6. And since that didn't fix the problem, that might point the finger back at C1 or C2. But that's purely a guess. On the other hand, I've also read that the Linux kernel can override the BIOS at times related to the C-states. Perhaps the unRAID kernel has simply been compiled with an option that isn't compatible with Ryzen. I checked the max C-state, (by running cat /sys/module/intel_idle/parameters/max_cstate ) and it came back with a value of 9, for C9. I have no idea if Ryzen supports C9, but if it does not, then perhaps unRAID is trying to enter C-states the processor doesn't support (the latest Intel CPU's can go up to C10). Or maybe this means nothing, I really don't know. There's still some pretty big lingering questions: Why is this C-state stability issue only happening in unRAID, and not other Linux distros? (I'm guessing a kernel compilation option that Lime-Tech is using). Why does it only affect Ryzen, and not the Bulldozer architecture? (I'm guessing the compiled options are confused by Zen but not by Bulldozer). Is this fixable? (I'm thinking it is, but will require Lime-Tech's involvement). Does this even need to be fixed, if we have a BIOS workaround? (To me, yes, because idle power consumption increased) So at this point, I'm done with my testing. I think I've pointed Lime-Tech in the direction of the C-states, and possibly the kernel compilation options related to C-states. This has all now greatly exceeded my Linux skill level and I won't be of any additional help. But in the mean time, at least we have a workaround, so my work here is done. For the very first time, I plugged in my 24-drive controller card and brought up my 42TB array up on Ryzen, and a parity check is chugging along nicely. It's been down for weeks during all this testing, and I've got a lot of data to get copied over (yesterday was World Backup Day, after all). Fingers crossed... -Paul P.S. - I'm also attaching two Diagnostics zip files, one with Global C-State Control enabled, and the other with it disabled. I used Beyond Compare on the two log files, and didn't see much related to ACPI or power managements, but perhaps they will prove useful to someone else. Global_C-state_Control_OFF_tower-diagnostics-20170401-0641.zip Global_C-state_Control_ON_tower-diagnostics-20170401-0641.zip

That's how I'd do it.

I am posting this to continue my contribution to this thread. As you all know I am a big supporter of these drives for the typical unRAID use case. My bi-directional transfer speeds are rock solid and the server supports several clients running concurrently 24 hours per day as well as early morning progressive backups. For those who don't want to read up, as of 29th March my Array configuration consisted of: Parity: 1 x Seagate 8TB Shingle Data: 5 x WD 3TB Red and 2 x WD 3TB Green and 1 x Seagate 8TB Shingle My monthly parity checks are: 2017-03-01, 20:02:50 19 hr, 32 min, 49 sec 113.7 MB/s OK 2017-02-01, 19:54:16 19 hr, 24 min, 15 sec 114.5 MB/s OK 2017-01-01, 19:47:18 19 hr, 17 min, 17 sec 115.2 MB/s OK 2016-12-01, 19:47:09 19 hr, 17 min, 8 sec 115.2 MB/s OK 2016-11-06, 06:49:45 19 hr, 42 min, 11 sec 112.8 MB/s OK On the 29th March 2017 I added a second Seagate 8TB Shingle as a second Parity. The subsequent Sync record was: On the 30th March 2017 I added a further Seagate 8TB Shingle as a data disk. The subsequent Clear record was: On the 1st April 2017 my monthly parity check ran. The record was: Following the parity check (as I rebooted to update to 6.3.3) one of the WD 3TB Green's failed. So I replaced it with a new Seagate 8TB Shingle. The subsequent rebuild record was: I then went on to replace the second WD 3TB Green from the system (as they were from the same batch as the one that had just failed) with another Seagate 8TB Shingle. The subsequent rebuild record was: For those not keeping score my new configuration is: Parity: 2 x Seagate 8TB Shingle Data: 5 x WD 3TB Red and 4 x Seagate 8TB Shingle I am satisfied with these figures. I am currently running a parity check on the system to see if my ~ 19 hour average remains. I will post when it does.

Ouch lol

These are the I/O read/write speeds and I/O read/write counters from /proc/diskstats. These numbers are stored in the file diskload.ini by a new daemon and used by the GUI in the Main page.

The disk I/O read and write speeds which are displayed on the Main page are now calculated in the background. The GUI used to do this, but now it simply needs to retrieve the obtained values from the daemon. Resulting in less overhead and more accuracy.

Updated for 6.3.3

NO => the spinners can easily exceed Gb speeds for writes. This may be a network issue; or it's possible the shares aren't configured to be cached -- in which case the writes are directly to the array ... in which case 40-50 MB/s is a reasonable speed (actually it's fairly good). If switching to reconstruct write mode (aka "turbo write") speeds things up, then that's indeed the problem. allischalmersman => Are you sure the shares are configured to use the cache? They have to be configured on a share-by-share basis.

40 to 60MB/s seems normal array write speed in default read/modify/write mode, you can change to reconstruct write (aka turbo write) and it should be considerably faster at the expense of all disks spinning up for writes. (settings -> disk settings) For the cache speeds seem low, try the script attached to rule out any network issues, copy it to root folder of your flash share and type: /boot/write_speed_test.sh /mnt/cache/test.dat write_speed_test.sh

@Squid Fingers crossed he doesn't delete the thread to destroy the evidence.....

Welcome to the unRAID forum. You can use "pwd" to view the directory you're in. Given, you copied the diskspeed.sh to the flash, you have to change to /boot after you login via telnet. /boot is the root of the stick You can list the content of a directory with "ls -l" Once you're in the directory that contains the script, try "diskspeed.sh" or "sh diskspeed.sh" (all without quotes"

Sorry for taking to long to reply, only just go a chance to have another look at the server. This worked a charm. Did just as you said and everything is working perfectly with correct permissions now. Thanks alot!! I also removed several of my plugins and am using the apps through the docker now, which I am really liking. Basically fixing this problem prompted me to update and overhaul the server and now it is working brilliantly, very impressed with what v6 can do now, i hadn't take the time previously to find out what the upgrade to v6 added. I have been running this same unraid machine since 2012 and rarely have any problems with it, but when I do this forum always helps me fix them. Thanks alot guys

The default permissions that CP, Sick et al set aren't proper. Within the programs, there's options set set permissions. You want it to be 0777 You really shouldn't run the new permissions tool, as it may muck up the operation of your programs. Install Fix Common Problems plugin, then within it set excluded shares to not touch any of the program files (aka appdata) for those plugins. Then under the tools menu, run Docker Safe New Permissions

Agree DVR is now in PlexPass. Works great for me. Using HDHomerun. Just been looking for commercial skipping. I also agree with above. A more standalone docker for multi use with other apps might be ideal (myth,tvhead,Plex). Just run a post script out of your primary media center tool to call the other tool to splice and dice and return back to library.

I'd recommend the HGST 8TB non-Helium for parity. https://www.bhphotovideo.com/c/product/1303685-REG/hgst_0s04012_8tb_3_5_sata_internal.html It is quite a bit faster (7200RPM vs 5400RPM), and would better support simultaneous writes. About the same price as the Red, which is actually slower than the archives. I can see no advantage to using the REDs for parity.

Telnet onto unraid (or from console if you have keyboard/monitor setup) Change directory to the UserShare you want cd /mnt/user/usershare1 chmod -R 777 * (that will recursively change permissions to read/write/execute for everyone from that directory and below)