unevent

My vote is to keep it as a plugin. If I want an ipod interface I will grab an ipod. This is nuts and bolts NAS with the primary mission of stability. Those that want frills and the risk of instability, use/create a plugin.

Couple other tweaks that may (in general) speed things up is to disable remote differential compression and disable TCP window auto tuning Link. Also if one is using maps to unRaid shares and using anti-virus, excluding those network maps from the anti-virus program could speed things up depending on the Win 7 system hardware.

SyncToy 2.1?

There are some changes to be made on the unraid side for the nfs exports and some changes to the pi side to make it work. Google produced a few hits, and this is one of them. You will need to edit the unraid exports file for permission restrictions (or perhaps a there is a way to do it through the GUI?) and also edit the pi cmd text file for the proper unRaid Linux distro nfs syntax. Easy way to start is to do a general nfs mount from the pi. Verify it works then configure it for nfs boot which there are many Google hits detailing the process - just have to use the proper commands for unraid distro. Good luck.

That is a good power supply for that price. Bought one last year when the price was $109 on sale. Lots of other companies have clones of the Seasonic with their own names on it. Who's Who In Power Supplies, 2013

Waiting for a plugin GUI like catfish myself.

Could I trouble you to include the cache_pressure as a configurable item in the php section and write the value to the cfg file to be read in on next load? You have it hard coded to 10 and not everyone uses that setting. It is great for a default, but would like the option to change it without editing the plugin file.

Your memory is a good amount. Whether or not the CPU is adequate is up to you and your tolerance level because loading at any one time is up to what plugins are actually doing something. Loading from a Linux standpoint, you can run "top" through telnet and see what the sysloads are doing over time. Since you have Cool n' Quiet enabled you can run the following in a telnet window: watch -n.1 'cat /proc/cpuinfo|grep MHz' It will show you what the processor frequency is in near real time. If it stays near max (2700) for long periods of time before dropping down it is a good piece of data to use in conjunction with sysload numbers to determine if the Sempron is truly overloaded. By default the governor is 'ondemand' and is rather poorly tuned so the cpu needs to be really hit hard to get sustained max speed. Unraid 5.0-rc10 - Asus M5A78L-MLX Plus (RT8111E) - AMD Athlon II X3 450 Rana 3.2GHz - 8GB DDR3 - Antec NEO ECO 620W - Antec Three Hundred Case - 1x Rosewill RC-211 (cache) - Parity: 1T Seagate ST1000DM005/HD103SJ - DATA: 3x WD Black 750G - 1x 1T Seagate ST1000DM003 - 1x 500G Seagate ST500DM002, Cache: Intel X25-V SSD 40GB w/8GB swap partition

Looking at the second syslog, I see you have 8GB ram with a Sempron 140 CPU running: couchpotato headphones mysql5 newznab sabnzbd sickbeard plex simplefeatures: active streams activity monitor cache.dirs core & webgui disk health email notify log viewer system information system stats web server and probably a couple more and with a couple drives in IDE mode. Browser may be timing out trying to access emhttp with that load depending on what was active at the time. It could take some time to respond if a couple of those addons are active. Have you checked for conflicting ports for the addons (web servers)? You said you tried to access the server via the ip address and not by name so the headphones cookie issue should not be the problem. There are a couple plugins in use that I have never used so not much else I can offer.

Sysload can be a misleading number if not interpreted correctly because IO waits make the load numbers quite large without any real load on the processor (waiting for IO). Unraid 5.0-rc10 - Asus M5A78L-MLX Plus (RT8111E) - AMD Athlon II X3 450 Rana 3.2GHz - 8GB DDR3 - Antec NEO ECO 620W - Antec Three Hundred Case - 1x Rosewill RC-211 (cache) - Parity: 1T Seagate ST1000DM005/HD103SJ - DATA: 3x WD Black 750G - 1x 1T Seagate ST1000DM003 - 1x 500G Seagate ST500DM002, Cache: Intel X25-V SSD 40GB w/8GB swap partition

List the add-ons you are actively using and your system hardware specs. A recent syslog would be nice as well. Just a guess from what I am seeing is something is using the disk heavily at the time you took the top capture which causes the %wa to shoot up which also causes the sysload numbers to go up. Need hardware info and what you were doing at the time (like writing a file via smb while processing a Sabnzbd downlod) to complete the picture.

Disable Subsonic either through the settings on the web page or manually edit the config file in the subsonic folder under plugins and set to 'disable'. You can keep your other plugins enabled and reboot. After reboot, mount the array and it should work. After the the array is online you can enable subsonic through the plugin settings page. From that point on it should work - at least it did for the scenario I went through. This happened to me when I cleared out all packages and had the plugins download fresh. To get a mount so you can cleanly reboot you may need to 'killall -9 subsonic' and/or 'killall -9 rc.subsonic' via telnet.

Was not my intention to associate crap with plugins or vice versa, only express crap-load of plugins in the context of limited hardware resources if that makes it sound better. The intention is to remove the crap-load of plugins from the RC10 memory issue at hand as well as perhaps plant the seed of better plugin control for another thread.

It is not an unRaid thing, it is a 32bit Linux thing. unRaid is just a driver and a set of tools written for an operating system. The fact it does not address above 4GB directly is not an unRaid thing it is a 32bit Linux thing. Linux uses all free memory for buffers which helps unRaid performance greatly when handling multiple streams at one. The Linux Kernel used has a bug. Either wait for a fix or roll back to a previous one.

Only if there is some relation between the cpu slowing down and the amount of memory... The problem is solved when you change the amount of allocated memory and/or the way the system deals with it.. Agree, there is certain hardware involved that is causing the memory allocation issues with how 32bit Linux addresses above 4GB ram (actually less) - those with flawed PAE implementation I would guess. That said, it is a rather limited set of hardware that has that bug and it is in the BIOS, chipsets and/or processor that it affects. 32bit linux (or any OS for that matter) cannot directly address more than 4GB ram, so if the kernel has PAE support along with the motherboard & CPU, it uses the processor to map/unmap as needed to the higher memory, as I understand it. It would be interesting to see that those with the problem disable SpeedStep or whatever is in use so their CPU runs at full speed in stock unRaid and test without the "4095M". I ran NFS and SMB tests with an 8GB system both reads and writes and found nothing other than SMB is slower than NFS, but still 30+ for SMB and 60+ for NFS with the test setup I used. The disk subsystem and the vm tune plays the major role with how well files are transfered over SMB or NFS with stock unRaid. If Tom were to disable plugins by default on the next test RC and then wait and see what effect it has I am sure we will be hearing something new, perhaps better. I would love to see the option for cache_dirs that allows one to change the cache_pressure easily instead of editing the file. The default may be too aggressive to use across the board when it is unknown how much crap people are running on a low memory and underpowered systems (as an example for addons). I find it hard for Tom to deliver a reliable 32bit product when the customization (plugin) window is wide open. Kind of like designing a new car and give it to someone to test and they go and add in a bunch of crap to suit their tastes then go back and complain the car isn't working. unRaid with addons should work, it has worked, but the bug in the Kernel, those with limited hardware (sure an Atom with 2GB can run 5 python/java plugins while transferring files at full speed over Ethernet, no problem), non-adjustable cache_pressure with cache_dirs, preclear scripts (and their resource requirements) and just about any addon made by just about anyone with a text editor with whatever libraries and packages they can scrap off the net to make it work with no defined rules or restrictions on how they are implemented and trying to release a piece of software as final? Fixing addons is for a different post, but a place to start is a set list of rules (or outline framework) for addon creation.

Update: Ran some NFS tests with rc10. I set up a couple 3GB tmpfs - one on unRaid with NFS export and the other on my Xubuntu PC. Using rsync on Xubuntu and a csv capture with bwm-ng on unraid: File sizes: several different TV shows of 2.2GB each Ram to Ram tmpfs via NFS: 117MB/s unRaid WD Black to Xubuntu Ram tmpfs via NFS: 103MB/s (WD Black reported 125MB/s with hdparm -tT) unRaid WD Black to Xubuntu disk via NFS: 65-73MB/s (w/ 1-3 second hiccups and wild fluctuations) (Disk limited on Xubuntu, hdparm -tT reported 73.76MB/s) Will do SMB next. UPDATE: I ran SMB read/write tests using Windows 7 64bit (Phenom 940, 8GB DDR2, RT8111DL) with 3GB Ram Drive using Dataram RAMDisk Utility. Used same 3GB tmpfs ram drive on unRaid as used for NFS tests. unRaid cache SSD is an older Intel X25-V that has not been TRIMed in some time and is getting ate up (hparm -tT shows 116MB/s). PC Disk is a WD Black SATA3 (for comparison, it's identical twin in unRaid shows 125MB/s with hdparm -tT). unRaid Parity drive is noted in the sig and the data drive in the array used for writes was the ST1000DM003 at hdparm -tT gave 178MB/s. Parity gave 145MB/s. No addons installed (except unmenu). To summarize SMB test pics: PC-Disk to unRaid Cache (no parity) Write: 38.54 MB/s PC-Disk to Array w/Parity Write: 31.54 MB/s PC-RAM to unRaid Cache (no parity) Write: 40.37 MB/s RAM to RAM Read: 116.77 MB/s RAM to RAM Write: 117.26 MB/s unRaid Data Disk to PC-RAM Read: 73.70 MB/s Unraid 5.0-rc10 - Asus M5A78L-MLX Plus (RT8111E) - AMD Athlon II X3 450 Rana 3.2GHz - 8GB DDR3 - Antec NEO ECO 620W - Antec Three Hundred Case - 1x Rosewill RC-211 (cache) - Parity: 1T Seagate ST1000DM005/HD103SJ - DATA: 3x WD Black 750G - 1x 1T Seagate ST1000DM003 - 1x 500G Seagate ST500DM002, Cache: Intel X25-V SSD 40GB w/8GB swap partition

I have the same deal with a 40GB SSD. My guess it is just a size it does not recognize. Unraid 5.0-rc10 - Asus M5A78L-MLX Plus - AMD Athlon II X3 450 Rana 3.2GHz - 8GB DDR3 - Antec NEO ECO 620W - Antec Three Hundred Case - 1x Rosewill RC-211 - Parity: 1T Seagate ST1000DM005/HD103SJ - DATA: 3x WD Black 750G - 1x 1T Seagate ST1000DM003 - 1x 500G Seagate ST500DM002, Cache: Intel X25-V SSD 40GB

I thought that only affected specific hardware? I don't believe it affects everyone and every hardware type. This isn't CNN

Release rc10 as final. Include known issues in the release notes for those that can read so they will understand the limitations with certain hardware. There will always be a small subset of hardware that doesn't work without issue and will need to be worked on. The problem with write speed is not isolated to the unRaid group so it will get more love from the larger audience and will have to roll the fix in when the kernel is updated. The write issue is not a Tom issue or an unRaid issue, it is a Linux issue so there is not much you can do about it anyway by holding final. Post a a bug report to Linus and move on. Moving to 64-bit kernel would be the next logical course for unraid, in my opinion.

Can do it two ways: create a mount point under an existing SMB or NFS export (under an existing share), or create a new export. NFS will be faster than SMB, but if your Windows not much choice. On unRaid: mkdir -m 777 /tmp/ramdrv or mkdir /mnt/disk1/ramdrv (do your own export manually or piggyback an existing one, respectively) _stop all addons_ (unmenu is fine) and clear the caches and see what is left when choosing the size: sync && echo 3 > /proc/sys/vm/drop_caches free -lm Create the ram drive: mount -t tmpfs -o size=3G tmpfs /tmp/ramdrv The size is important and should be chosen conservatively if you don't have a swap partition enabled. G = Gig, M = Meg and so on. Tmpfs will be created with a set max size - will not grow more than what you tell it. It will also be swappable if you have a swap partition enabled, which is nice for those oops as it keeps the server from crashing. If you piggybacked an export, browse (Windows) to the network, then choose disk1 and it will be there. If you want to roll your own export, edit the export file (nfs) or samba config and restart the service. To capture a csv file with bwm-ng of the transfers on runraid (install bwm-ng via unmenu), telnet in and: bwm-ng --output csv -F transfer_log.csv --count 1000 --interfaces eth0 Start the command and run your transfer. Hit CTRL-C if the transfer finishes and bwm-ng is still logging or increase the count if it ends early (scary). Edit the file to add the headings below to the top: unix_timestamp;iface_name;bytes_out;bytes_in;bytes_total;packets_out;packets_in;packets_total;errors_out;errors_in Import into your favorite spreadsheet program. Delete the last columns with no headings. Sort to separate the "total" rows and delete, sort ascending using timestamp. Plot vs timestamp however you want. I'd post one of my NFS plots, but don't have a pic hosting site. The plots are only exciting when they are crazy with hiccups and dropouts in the transfers. Another tidbit is to watch for dropped packets if you suspect network trouble, in another telnet session: watch -n.1 'ifconfig|grep dropped' Drops while nothing going on is most likely framing errors that is being reported as dropped. Drops during a transfer is more important to watch for.

Update: Ran some NFS tests with rc10. I set up a couple 3GB tmpfs - one on unRaid with NFS export and the other on my Xubuntu PC. Using rsync on Xubuntu and a csv capture with bwm-ng on unraid: File sizes: several different TV shows of 2.2GB each Ram to Ram tmpfs via NFS: 117MB/s unRaid WD Black to Xubuntu Ram tmpfs via NFS: 103MB/s (WD Black reported 125MB/s with hdparm -tT) unRaid WD Black to Xubuntu disk via NFS: 65-73MB/s (w/ 1-3 second hiccups and wild fluctuations) (Disk limited on Xubuntu, hdparm -tT reported 73.76MB/s) Will do SMB next. Unraid 5.0-rc10 - Asus M5A78L-MLX Plus - AMD Athlon II X3 450 Rana 3.2GHz - 8GB DDR3 - Antec NEO ECO 620W - Antec Three Hundred Case - 1x Rosewill RC-211 - Parity: 1T Seagate ST1000DM005/HD103SJ - DATA: 3x WD Black 750G - 1x 1T Seagate ST1000DM003 - 1x 500G Seagate ST500DM002, Cache: Intel X25-V SSD 40GB

To view the active governor (if throttling is enabled such as AMD Cool and Quiet) cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor Repeat and increment "cpu0" for each core of the processor (cpu0, cpu1 for dual core) To get a list of available governors: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors Mine shows ondemand, performance. Performance is no throttling - CPU cores run at full speed. There are other governors and there is the option to enable more, but for the sake of error-free logs during parity checks ondemand or performance would be the recommendation. To change the governor of a CPU core to "performance": echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor The above command should be repeated for each core (cpu0, cpu1, cpu2, etc) that you want to change the governor for. To revert back you can either reboot or change "performance" to "ondemand" or whatever your original governor was and repeat the command for each core you want to change. EDIT: This post may benefit being moved or copied to another area Alternatively, you can adjust the ondemand governor thresholds to get better performance without forcing the cores to remain at full speed continuously: To watch the cpu frequency in real time: watch -n.1 'cat /proc/cpuinfo|grep MHz' To view the current value the CPU usage percentage must average (in the sampling period) before the kernel makes a decision to increase the frequency: cat /sys/devices/system/cpu/cpufreq/ondemand/up_threshold The default is 80, which means the cpu must average above 80% usage (in the sampling period) before the kernel starts increasing the frequency To change this CPU usage threshold: echo 30 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold This will set the usage to 30%, as an example. Average CPU usage above 30% will cause the kernel to start increasing frequency To view the factor that the kernel applies to the scheduling interval to determine how quickly the frequency should be brought back down: cat /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor default is 1, which is the fastest (regardless of clock speed) the frequency will be brought back down. To change the delay (factor) to slow the rate the kernel will bring the frequency back down from top speed: echo 50 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor Valid values are 1 (default) to 100000. Watching the cpu frequency in real time while running the tasks you are troubleshooting and changing the values on the fly via telnet is an easy way to tune these numbers and produce a more responsive system without resorting to full heat production and power consumption of running the CPU at full speed continuously. Note these values will be lost on reboot unless called from a script at boot. Unraid 5.0-rc10 - Asus M5A78L-MLX Plus - AMD Athlon II X3 450 Rana 3.2GHz - 8GB DDR3 - Antec NEO ECO 620W - Antec Three Hundred Case - 1x Rosewill RC-211 - Parity: 1T Seagate ST1000DM005/HD103SJ - DATA: 3x WD Black 750G - 1x 1T Seagate ST1000DM003 - 1x 500G Seagate ST500DM002, Cache: Intel X25-V SSD 40GB

Made the switch to rc10 from rc8a, have Realtek 8111E - no problems. Ran iperf on rc8a before switch: 112MB/s to/from, ran same test with rc10 and got same values. Client is Xubuntu 12.10 with Realtek 8111DL. Have not tested NFS or SMB yet. Ran permissions utility with no issues. Started non-correcting parity check and got 80-90MB/s at first. Changed cpu scaling governors for the three cores via telnet to performance and it opened up to ~120 with occasional dips to ~113MB/s. Parity check in line with what it was for me on rc8a. No addons installed for these tests other than unmenu. mike@BLUE:~/Desktop$ iperf -c 192.168.150.45 -f M -i 1 -p 5001 -r ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 0.08 MByte (default) ------------------------------------------------------------ ------------------------------------------------------------ Client connecting to 192.168.150.45, TCP port 5001 TCP window size: 0.20 MByte (default) ------------------------------------------------------------ [ 5] local 192.168.150.36 port 59986 connected with 192.168.150.45 port 5001 [ ID] Interval Transfer Bandwidth [ 5] 0.0- 1.0 sec 112 MBytes 112 MBytes/sec [ 5] 1.0- 2.0 sec 112 MBytes 112 MBytes/sec [ 5] 2.0- 3.0 sec 112 MBytes 112 MBytes/sec [ 5] 3.0- 4.0 sec 112 MBytes 112 MBytes/sec [ 5] 4.0- 5.0 sec 112 MBytes 112 MBytes/sec [ 5] 5.0- 6.0 sec 112 MBytes 112 MBytes/sec [ 5] 6.0- 7.0 sec 112 MBytes 112 MBytes/sec [ 5] 7.0- 8.0 sec 112 MBytes 112 MBytes/sec [ 5] 8.0- 9.0 sec 112 MBytes 112 MBytes/sec [ 5] 9.0-10.0 sec 112 MBytes 112 MBytes/sec [ 5] 0.0-10.0 sec 1122 MBytes 112 MBytes/sec [ 4] local 192.168.150.36 port 5001 connected with 192.168.150.45 port 53466 [ 4] 0.0- 1.0 sec 112 MBytes 112 MBytes/sec [ 4] 1.0- 2.0 sec 112 MBytes 112 MBytes/sec [ 4] 2.0- 3.0 sec 112 MBytes 112 MBytes/sec [ 4] 3.0- 4.0 sec 112 MBytes 112 MBytes/sec [ 4] 4.0- 5.0 sec 112 MBytes 112 MBytes/sec [ 4] 5.0- 6.0 sec 112 MBytes 112 MBytes/sec [ 4] 6.0- 7.0 sec 112 MBytes 112 MBytes/sec [ 4] 7.0- 8.0 sec 112 MBytes 112 MBytes/sec [ 4] 8.0- 9.0 sec 112 MBytes 112 MBytes/sec [ 4] 9.0-10.0 sec 112 MBytes 112 MBytes/sec [ 4] 0.0-10.0 sec 1128 MBytes 112 MBytes/sec mike@BLUE:~/Desktop$ Unraid 5.0-rc10 - Asus M5A78L-MLX Plus - AMD Athlon II X3 450 Rana 3.2GHz - 8GB DDR3 - Antec NEO ECO 620W - Antec Three Hundred Case - 1x Rosewill RC-211 - Parity: 1T Seagate ST1000DM005/HD103SJ - DATA: 3x WD Black 750G - 1x 1T Seagate ST1000DM003 - 1x 500G Seagate ST500DM002, Cache: Intel X25-V SSD 40GB

I'm by no means a Linux expert, but what do the *ubuntu guys do? I have Xubuntu on several systems with Realtek NICs and they use the 8169 driver. Obviously different distro (Debian vs Slack), but do they probe and select based on a config file or something?

or df -h console is where you have a keyboard/monitor on your server and are right there versus accessing by telnet over the network