ufopinball

Upgraded from 7.2.0 to 7.2.3, no issues. Thanks!!

Updated from 6.12.12 to 6.12.14. So far 2+ days of uptime, no issues.

UnRaid identifies drives by serial number, so motherboard SATA ports should definitely be fine. Add-in SATA PCIe cards should also be fine, but I don't believe USB connections are supported. Not sure about the M.2 slot idea as I haven't tried it. But, since it's newer technology, hopefully they've thought to support things like this. Just make sure all your drives show up and are properly accounted for before you start the array.

Hmmm, they’re no longer running as my primary system, but they seemed okay before. Any idea how to get the ASRock x399 Taichi to play nice with LSI controllers? Or what’s a good option outside of LSI and Marvell?

Sadly, the ASRock x399 Taichi MB just doesn't play well with LSI controller cards. Here's a conversation on Reddit that goes into greater detail: https://www.reddit.com/r/unRAID/comments/98kdyp/lsi_920116i_and_asrock_taichi_x399/ I've got the same setup, and I've never gotten it to work. I ended up going with dual AOC-SAS2LP-MV8 (Marvell based) controller cards. That was many years ago, so there may be newer alternatives, but I know they work with this MB and a Threadripper 1950X. The two Dell Perc H310 (LSI based) controllers that ASRock didn't like, work just fine in an ASUS MB, so I know they're functionally okay.

Updated smoothly from 6.8.3 --> 6.9.1 --> 6.9.2. No issues to report, everything seems to be running as it should. Thanks LT!

I upgraded my server (AMD Ryzen Threadripper 1950X) and had no problems whatsoever. Uptime is a little over 2 days, have not had issues with booting, dockers, VMs, etc. I'm not sure what you mean by "cpu insulation"? My MB is the ASRock x399 Taichi, if it matters. Full specs in signature line.

I upgraded my server, everything seems to be going smoothly. No issues with updates, Dockers, transfer speeds, etc. I did bump into the NoVNC bug once, but it didn't persist. So far my uptime is 6+ days so I guess I meant to post this earlier. Really enjoying being able to copy files on the server while the family is watching something on Plex. Thanks for all the efforts, LT!!

Updated my server from 6.7.1 to 6.7.2 last week, and have had no problems on my Threadripper 1950X build. Previous Uptime: 38d, 14m Current Uptime: 8d, 5h, 48m Thanks for all the hard work!!

I'm sure you're right. I did buy an AOC-SAS2LP-MV8 at one point in time, I must have lost track of which one I have in the machine. Thanks for the sharp eye!

Hmmm, well I don't have the card in hand, but that's what I thought I bought off eBay some years ago. System Devices reads as follows: RAID bus controller: Marvell Technology Group Ltd. 88SE9485 SAS/SATA 6Gb/s controller (rev 03) So, dunno?

Upgraded from 6.6.7 to 6.7, haven't had any problems. Previous uptime: 75d, 19h, 58m Current uptime: 9d, 1h, 21m According to "System Devices", my Dell HV52W PERC H310 controller has a Marvell chipset (88SE9485). As far as I know, people on this chipset are not seeing the missing drives issue? I have not had any issues on my system so far. My next step is to do the "amd_iommu=pt", but for the moment, things are running smoothly.

Upgraded from 6.6.6 to 6.6.7, no problems with Dockers (Plex, Sickbeard) or VMs (LAMP, Win10, Win7) Uptime for 6.6.6: 67 days, 9 hours, 30 minutes Uptime for 6.6.7: 15 hours, 4 minutes and counting

Upgraded from 6.6.5 to 6.6.6 a few days ago ... no smoke, no fires.

My ASRock x399 Taichi is on BIOS 3.30. In the BIOS the AGESA field reads: ThreadRipperPI-SP3r2-1.1.0.1. The BIOS on the ASRock website is dated 8/21. Is there a list of things fixed in the 'A' update?

Guess that makes the difference. The 1700 is a 3.0/3.7 GHz, 65 watt CPU, and the 1800X is a 3.6/4.0 GHz 95 watt CPU. I'm still thinking I could have easily gotten by with a 1700 chip. I doubt I stress out the 1800X enough to justify the price/power costs. I'll likely rethink which model I upgrade to when Zen2 comes out. - Bill

Looks good, which CPU and MB do you have? My Ryzen 1800X idles at 42c (at best) with nothing running but unRAID. All dockers and VMs are stopped. The only thing "loaded" is a window to the web UI on the "Main" tab to show the current temp. The UPS is reporting 45 watts, and that's with all drives spun down. If you're getting lower 30s, I'm wondering what I may be doing wrong? Chip isn't overclocked or anything. I guess 45 watts isn't *bad*, but if it could be better, I'd like to find out what I'm doing differently. My specs are in my signature. Thanks! - Bill

Yes, well sort of anyway. The full details are posted in another thread: https://forums.lime-technology.com/topic/55150-anybody-planning-a-ryzen-build/?page=19#comment-563450 It's definitely an interim solution, though I don't know if/when a more official solution will be made available. Let me know if you have problems getting this working... - Bill

Hi bonienl, I would also like to echo my thanks for your plugin. I just upgraded my unRAID to use the new AMD Ryzen 1800X 8-core CPU, with the ASUS Prime X370-PRO motherboard. I had to disable to existing Dynamix System Temp plugin because it was still expecting sensors from the previous system, and therefore was causing system instability. Looking around, I found this thread: https://www.reddit.com/r/Amd/comments/618nyc/linux_lmsensors_it87_support_for_some_am4/#bottom-comments They're discussing an update to the it87 driver that supports a chip (?) called IT8665E used on some X370 motherboards. I added a fresh copy of the Dynamix System Temp plugin, but at present these sensor options don't seem to be available. In order to support the newer drivers, does this require an update to the Dynamix System Temp plugin, or a newer unRAID? I'm running unRAID 6.3.2 PRO. Thanks!! - Bill

Ran the script from the above post, selected the 10 minute test, and the full iterations ran for 2 1/2 hours ... results were: Tunable (md_num_stripes): 1280 Tunable (md_write_limit): 768 Tunable (md_sync_window): 384 Basically what I had before, but for some reason "md_write_limit" was blank? I don't have a screen shot, but that's what the tool reported. Anyway, I guess my Cortex server has been running reasonably optimally all along. Good to know, though... Squid updated it so it would run, with 6.2, but it's not actually valid for 6.2. As of 6.2, md_write_limit is gone and md_sync_thresh has been added, with a default value of 192. Your md_sync_window would be fine at 384, twice the value of md_sync_thresh, but would probably show worse performance with higher values of md_sync_window. According to Tom, md_sync_thresh needs to be in the range of (md_sync_window/2) to (md_sync_window-1). We're waiting for an updated tunables script. Thanks RobJ ... was wondering what all the hub-bub was about waiting for a 6.2 script if we had one. Guess we don't really... I just looked in my disk.cfg file, and there is no entry for md_write_limit ... so I guess the setting added by the older script was removed by the system? I'm not sure where else to look. The rest of the md_* settings look like this: md_num_stripes="1280" md_sync_window="384" md_sync_thresh="192" md_write_method="auto" The older tunables script reported 131.9 MB/s with these settings. Does that look/sound decent? Thanks!

I too have been enjoying this tool, has helped with some testing I've been doing. Thanks! We're getting off-topic though, perhaps it deserves its own thread? Running the latest version - the Total column looks more like an average to me. I would have expected a sum? Is this plugin still around? The link doesn't work... Squid updated it to 6.2 here http://lime-technology.com/forum/index.php?topic=29009.msg492140#msg492140 Ran the script from the above post, selected the 10 minute test, and the full iterations ran for 2 1/2 hours ... results were: Tunable (md_num_stripes): 1280 Tunable (md_write_limit): 768 Tunable (md_sync_window): 384 Basically what I had before, but for some reason "md_write_limit" was blank? I don't have a screen shot, but that's what the tool reported. Anyway, I guess my Cortex server has been running reasonably optimally all along. Good to know, though...

Nope

16GB (4x4GB) of DDR2 800 (PC2 6400)

+1 +1 +1 +1 +1 +1

The pre-read throws away the contents of what is being read (sends it to /dev/null) Its whole purpose is to let the firmware on the disk identify un-readable sectors. The post-read verifies all that is being read is all zeros. (actually analyzes what is being read) It is normal for it to take longer because of that. Joe L. Thanks Joe ... my apologies for not digging through the 110 (!!) pages of this thread. Your tool is most helpful, and obviously very popular! With 4TB drives being available, and assuming larger drives will be in our future ... are there any ways to boost the post-read speed? This is a test rig running on an AMD Phenom 9950 X4 2.6GHz cpu and 8gb of DDR2 RAM, if that helps at all ... or is the bottleneck still the drive (and interface?) itself?