nid

For me this solution works for both sleep and shutdown state. Currently I have the following controller from Tp-Link: 01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) Very strangely but maybe just pure coincidence, soon after upgrading to 6.7.2 my Intel pro 1000 CT which was fine for about three years suddenly started dropping out, giving errors like "hardware not found", about 30-60 minutes after system booting. This made me go out and buy the Tp-link with Realtek chipset and of course afterwards I came across the WOL issue... A great combo of annoyance... Of course I will test the Intel NIC again when I find the time.

Yes I'm using it for automatic suspension after a specific amount of array inactivity. But I also like to be able to do it manually with a single double click. I don't like the fact that the root password is exposed like that in the Bat file (of course it's just in a home environment).

Thanks it works, both ways.

Yes it's working when I type in a local terminal but how to send it through a batch file from Windows? I tried with plink and it doesn't work, but maybe the syntax is incorrect: plink.exe -ssh -pw yourpassword root@yourIP echo -n mem > /sys/power/state

Surprised by the silence in this forum with so knowledgeable people. Although I've already searched about this around the internet and couldn't find any clear info. Perhaps it is just not possible (yet)?

Bump

I'm already using a bat file for powering down and it works fine. It has the following code: plink.exe -ssh -pw yourpassword root@yourIP powerdown How to do the same to send a suspend/sleep command? Windows 10 and Unraid 6.6.2

Thanks for the info but the issue with my system is the inconsistent read transfer rates, that I cannot explain. I think the advice I need is what and how to monitor while performing a read from the array to a Windows machine. What info should I be looking for at the time the big drops are taking place or vice versa when it rises up again to maximum gigabit speed.

Good idea! I tried some copies within mc and the rate is mediocre. 10-30MB/sec, mostly staying close to 15, but fluctuating. What could this mean? Is it a valid test copying from a disk to itself? There is great probability that's what's happening since I only have 2 disks + parity.

Copying between my two Windows 10 workstations I have this "just a few and short" drops. It is so infrequent and totally acceptable. But copying from the Unraid array the drops are huge and long, from 110MB/sec to 20MB/sec, going up and down like the screenshots I posted before. Even copying the same file (after some time has passed when it seems it's not anymore cached) shows a different copy curve, which leads me to believe it is not file based or where the data resides on the disk platter. I guess even in the innermost area the WD RED is faster than 20MB/sec. Destination drives are always SSD (windows 10 system) drives.

More info is in the previous posts (with the old hardware). I change m/b, cpu and ram, keeping everything else exactly the same. I notice that now I can reach full gigabit speeds for most of the time, just not steady, which is the annoying part. I upload new diagnostics as of today. As far as I can tell the system is perfectly healthy and is almost without any load. Rutorrent is rarely (almost never these days) doing any transfer and Crashplan is backing up 2 windows pcs every 24 hours and I know when that is, so I'm not testing at the same time. Fix Common Problems says everything is fine. As everyone knows, one could test thousand of different scenarios (turn off this and that and try again etc) but I don't have time nor patience anymore to do that. As a last resort I could try a fresh Unraid installation but it is so much work and hassle that I'm very skeptical about it yet. To be honest after about 3 years I'm just disappointed from Unraid. I should be happy of course because at last I have lots of moments with top performance... This shows to me that the hardware can do it. What about the (paid) software? Still don't take me wrong, I admire the amazing work that has been done with Unraid. Well perhaps that says it all... And I remember along the years I've been coming across many posts with people complaining about transfer rate issues. tower-diagnostics-20180502-2335.zip

I forgot to mention that I don't use a cache drive. Let's say OK about the writes. But what about the reads? Why is it so inconsistent even if there is no other load on the system or the network? Between my Windows machines the copies of large files get steady maximum gigabit speed, when there is no other significant load. I tried just now. And also tried again with Unraid, managed to copy around 10GB of various large files pinned to 110MB/sec. After that again the same sloppiness.

I attach some screenshots of the Windows copy dialog. I start with a just rebooted Unraid server and first two copies are reaching top speed 110MB/sec. Files tested are always single 1-4GB files. Subsequent copies start showing this kind of ramping. Copy to the array also shows the same. Maybe has to do with RAM getting filled up?...

Hi. I did a test replacing the system with an older but much more powerful one that I had sitting around. Old system: Asrock e35lm1 (weak single core AMD E240) with 8GB DDR3 1066 Power consumption with all 4 disks spinning: 50W New system: Asus P5E with Intel Quad Core Q9650 @3GHZ and 4GB DDR2 800 Power consumption with all 4 disks spinning: 75W This processor is of course much faster and never hits 100% during copies, unlike the suffocating AMD. Maximum cpu % I've seen was around 55%. Now I can achieve copy speeds of up to 110MB/sec. But there is still no consistency. Sometimes the speed will drop down to 10MB/sec and even less and then slowly rise up. Another time just stays low throughout the whole copy. Another time yet reaches full speed throughout the whole copy. Even while copying the same large file. I'm talking about getting data from the array to the Windows PC. I'm using various random sample files from my collection to make this observation. Tried also the two NIC settings (offload etc) but didn't see any change. NIC is the same Intel 82574L. Don't know if it would make sense to try the onboard Marvell... I feel it is a software thing and currently not very trustful about Unraid performance until I see some solid performance, not with super expensive server grade hardware or even expensive workstation (say like an i7 machine). Just for copying data! Perhaps I should have just used some Linux distro for this but I've already purchased Unraid and it is also lovely for its simplicity. Moreover, I don't like this consumption increase. There is also an audible noise increase due to the higher demand for cooling of the Intel Core Quad. Who can recommend a modern cost effective and low consumption system (mb/cpu/ram) that can handle just data i/o with full gigabit speeds and Crashplan and Rutorrent running as dockers? I need it to run cool and silent 24/7, so it doesn't need to be a monster. The Asrock board was close but not there due to the extremely feeble performance. By the way I had taken advice by an older blog of someone to get that motherboard. Not very successful advice. Thanks!!

Yeah either to leave it as is and not spend any more time troubleshooting or upgrade the hardware. Thanks for your time! Cheers

Exactly, now as you see almost everything is 0 and for some reason can't be changed.

I use the command to change some of the parameters but their status doesn't change. For example adaptive rx and tx remain off. Also tried other values for tx-usecs etc. but they don't change. Any ideas? root@Tower:~# ethtool -C eth0 adaptive-rx on root@Tower:~# ethtool -C eth0 adaptive-tx on root@Tower:~# ethtool -c eth0 Coalesce parameters for eth0: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 3 rx-frames: 0 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 0 tx-frames: 0 tx-usecs-irq: 0 tx-frames-irq: 0 rx-usecs-low: 0 rx-frame-low: 0 tx-usecs-low: 0 tx-frame-low: 0 rx-usecs-high: 0 rx-frame-high: 0 tx-usecs-high: 0 tx-frame-high: 0

I noticed that actually the higher the copy speed goes, the higher the %CPU of shfs is. Also the write (to Array) speed is faster (70mb/sec) than the read speed (50mb/sec). Test on the same file.

Just tried. It doesn't get better. Copy speed is now inconsistent (going below but also over 50mb/sec) and shfs has even higher %CPU.

While copying this is the output of top:

That's why I bought the external Intel 82574L PCIe but I didn't see any greatness ever after I switched from the onboard (probably Realtek) NIC. Do you know where I can check and set the setting for "IRQ Coalescing" for the Intel NIC? I have Netdata installed and I captured two screenshots for you during receiving a large video file from the server. You can see this "brick" curve on the right. This was a steady 50mbyte/sec copy. Of course the WD Red could reach 100mbyte/sec as far as I know. mpstat during the copy is showing around 6000/second. According to the article anything over 5000/second is a lot. Also I found that IRQs 24 and 25 have the most requests and here is the list: root@Tower:~# cat /proc/interrupts CPU0 0: 143 IO-APIC 2-edge timer 8: 3 IO-APIC 8-edge rtc0 9: 0 IO-APIC 9-fasteoi acpi 14: 0 IO-APIC 14-edge pata_atiixp 15: 0 IO-APIC 15-edge pata_atiixp 17: 593202 IO-APIC 17-fasteoi ehci_hcd:usb1, ehci_hcd:usb2, ehci_hcd:usb3 18: 727490 IO-APIC 18-fasteoi ohci_hcd:usb4, ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7 19: 526037 IO-APIC 19-fasteoi ahci[0000:00:11.0] 24: 3410481 PCI-MSI 524288-edge eth0-rx-0 25: 2148133 PCI-MSI 524289-edge eth0-tx-0 26: 2 PCI-MSI 524290-edge eth0 NMI: 0 Non-maskable interrupts LOC: 53314583 Local timer interrupts SPU: 0 Spurious interrupts PMI: 0 Performance monitoring interrupts IWI: 21269020 IRQ work interrupts RTR: 0 APIC ICR read retries RES: 0 Rescheduling interrupts CAL: 0 Function call interrupts TLB: 0 TLB shootdowns TRM: 0 Thermal event interrupts THR: 0 Threshold APIC interrupts DFR: 0 Deferred Error APIC interrupts MCE: 0 Machine check exceptions MCP: 266 Machine check polls HYP: 0 Hypervisor callback interrupts ERR: 0 MIS: 0 PIN: 0 Posted-interrupt notification event NPI: 0 Nested posted-interrupt event PIW: 0 Posted-interrupt wakeup event So far so good but I don't know what these results exactly mean... Thanks so far for all the help

I know the machine sucks but it's not doing much except for copying data from/to it and running Rutorrent and Crashplan. It was built with low consumption in mind and it's pretty good at that. Right now (after disabling those two settings in Tips and Tweaks) I think it is mostly as good as it used to be. It is just not consistent. I keep testing randomly once every now and then and sometimes speeds are ok sometimes they are not. This can also be seen with smaller files, for instance photo folders where you can see how fast or slow the Windows thumbnails generation is getting done. The image files are between 1 and 15 MB. I can say on average terms we are OK here. It is a (cheap) home server after all. It is just a bit annoying and disappointing when it gets slow at moments when you need it, for example when my wife wants to pick and edit photos from a folder with many files. She complains why it is now so slow, it used to be faster etc. But it was never super fast. Not Gigabit fast. If it was a read from a share from a Windows machine I believe it would be snappier and more consistent. And the disappointing fact is that Unraid is a Linux based system which ought to be a great performer. I would have built just another Windows system as a file server if I knew that it would perform like that. Can my motherboard with the weak AMD E240 be the only reason for not being able to achieve optimal performance (close to Gigabit speeds)?

I don't know how to interpret the printout of tcpdump. Here I copy/paste a portion of it while copying a large file. By the way while tcpdump is running the copy speed is dropping by 10-20mbyte/sec. Don't know if that says something. 23:00:34.133753 IP 192.168.1.2.59261 > 192.168.1.250.microsoft-ds: Flags [P.], seq 115894:115986, ack 309468225, win 21072, length 92 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.134509 IP 192.168.1.250.microsoft-ds > 192.168.1.2.59261: Flags [P.], seq 309468225:309468353, ack 115986, win 2864, length 128 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.136465 IP 192.168.1.250.http > 192.168.1.2.59383: Flags [P.], seq 379293:379506, ack 1, win 69, length 213: HTTP 23:00:34.139331 IP 192.168.1.2.59261 > 192.168.1.250.microsoft-ds: Flags [P.], seq 115986:116270, ack 309468353, win 21072, length 284 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.141518 IP 192.168.1.250.microsoft-ds > 192.168.1.2.59261: Flags [P.], seq 309468353:309468717, ack 116270, win 2864, length 364 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.142216 IP 192.168.1.2.59261 > 192.168.1.250.microsoft-ds: Flags [P.], seq 116270:116378, ack 309468717, win 21070, length 108 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.142619 IP 192.168.1.250.microsoft-ds > 192.168.1.2.59261: Flags [P.], seq 309468717:309468857, ack 116378, win 2864, length 140 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.143149 IP 192.168.1.2.59261 > 192.168.1.250.microsoft-ds: Flags [P.], seq 116378:116470, ack 309468857, win 21070, length 92 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.143609 IP 192.168.1.250.microsoft-ds > 192.168.1.2.59261: Flags [P.], seq 309468857:309468985, ack 116470, win 2864, length 128 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.145928 IP 192.168.1.250.http > 192.168.1.2.59383: Flags [P.], seq 379506:379710, ack 1, win 69, length 204: HTTP 23:00:34.146451 IP 192.168.1.2.59383 > 192.168.1.250.http: Flags [.], ack 379710, win 2051, length 0 23:00:34.155464 IP 192.168.1.2.59261 > 192.168.1.250.microsoft-ds: Flags [P.], seq 116470:116778, ack 309468985, win 21069, length 308 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.156380 IP 192.168.1.250.http > 192.168.1.2.59383: Flags [P.], seq 379710:379860, ack 1, win 69, length 150: HTTP 23:00:34.157881 IP 192.168.1.250.microsoft-ds > 192.168.1.2.59261: Flags [P.], seq 309468985:309469349, ack 116778, win 2864, length 364 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.158617 IP 192.168.1.2.59261 > 192.168.1.250.microsoft-ds: Flags [P.], seq 116778:116886, ack 309469349, win 21068, length 108 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.159093 IP 192.168.1.250.microsoft-ds > 192.168.1.2.59261: Flags [P.], seq 309469349:309469489, ack 116886, win 2864, length 140 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.160613 IP 192.168.1.2.59261 > 192.168.1.250.microsoft-ds: Flags [P.], seq 116886:116978, ack 309469489, win 21067, length 92 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.161230 IP 192.168.1.250.microsoft-ds > 192.168.1.2.59261: Flags [P.], seq 309469489:309469617, ack 116978, win 2864, length 128 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.166520 IP 192.168.1.250.http > 192.168.1.2.59383: Flags [P.], seq 379860:379977, ack 1, win 69, length 117: HTTP 23:00:34.167062 IP 192.168.1.2.59383 > 192.168.1.250.http: Flags [.], ack 379977, win 2050, length 0 23:00:34.172370 IP 192.168.1.2.59261 > 192.168.1.250.microsoft-ds: Flags [P.], seq 116978:117102, ack 309469617, win 21073, length 124 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.172789 IP 192.168.1.250.microsoft-ds > 192.168.1.2.59261: Flags [P.], seq 309469617:309469797, ack 117102, win 2864, length 180 SMB-over-TCP packet:(raw data or continuation?) 23:00:34.173442 IP 192.168.1.2.59261 > 192.168.1.250.microsoft-ds: Flags [P.], seq 117102:117210, ack 309469797, win 21072, length 108 SMB-over-TCP packet:(raw data or continuation?) ^C 21570 packets captured 26361 packets received by filter 4776 packets dropped by kernel

Ok, ifconfig shows 5 dropped packets RX packets 12685671 bytes 15279444400 (14.2 GiB) RX errors 0 dropped 5 overruns 0 frame 0 TX packets 16707800 bytes 23779571302 (22.1 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 This is in 18 hours online. I guess it's nothing to worry about?

Ok the difference is that no matter if set to On or Off the status of Flow Control on mine stays always Off.