darkside40

Does anybody has a clue what happened to @gfjardim or @Joe L.? Both Maintained Preclear Scripts. @Joe L. was last time online in 2019 but also @gfjardim was the last time online in June. From that time on also nothing happened in his Github Repo, so i am a little bit worried.

Wieviel Watt hat das denn effektiv gebracht wenn die CPU die tieferen Schlafzustände erreichen konnte?

Dann werd ich, wenn ich die Möglichkeit habe mal nachmessen was das ausmacht.

Gibt es denn Unterschiede bei den Karten bzw deren Chipsets oder muss man damit leben das man keine tiefen C-States erreicht?

Moin Leute, muss ja sagen der Thread ist ziemlich Interessant. Mein unRaid läuft in seiner derzeitigen Konstellation ja jetzt schon 5 Jahre und damals gab es meines Wissens keine Möglichkeit alles so einfach mit Powertop zu optimieren. Also Powertop gab es schon, bloss keine Möglichkeit es vernünftig mit unRaid zu nutzen. Habe derzeit einen i5-4570T auf nem Gigabyte GA-H87M-HD3 verbaut. Auf dem Board sitzt auch noch ein Adaptec AAR-1430SA Sata Controller. Da bei mir demnächst mal ein Hardware Upgrade ansteht hab ich mich so ein bisshen quer durchs Forum gelesen und nun stellt sich mir die Frage ob ich auch die Adaptec AAR-1430SA die ich drin habe rauswerfen soll. Mir ist nämlich aufgefallen das PKG C-State eingentlich nie niedriger als C3 wird. Kann die Sata Karte dafür ein Grund sein? Gibt es ggf. einfache M2 PCIe zu Sata Adapter die diesen negativen Effekt nicht haben (schon im Hinblick auf den Hardware Tausch)? Leider hab ich jetzt am WE keine Zeit aber vielleicht sollte ich doch mal probieren ob die C-States sich ändern wenn ich die Karte entferne (ohne Array autostart).

Yes that possible, just put multiple IP's to that field separated by a comma.

Die Meldungen tauchen bei mir auch auf. Scheinbar sind bei mir die Timeouts so gut gewählt das der Server sich idR auch schlafen legt. Hat irgendeiner einer Idee warum emhttpd zwischendurch einfach Smart Werte aktualisiert?

Thats too bad, a bit more info about this would be useful. If it is based on reliable approach that could be used to determinate if the array is inactive.

Nobody?

While i was fixing some problems with my current unRaid 6.9 Setup i came across the disks.ini file and saw that it featured a value named spundown. Could somebody explain how that value is retrieved? DiskIO counter? hdparm or completely different? There are several approaches an to be honest some of them are not really precise.

Thanks for the hint. Had the same problem on Manjaro. Being honest it is a pity that you have to google how to to generate a unRaid USB Stick under Linux.because there is no description for it on the Homepage. There is only an installer for Windows and Mac OS.

I have gfjardims preclear script install and dont have the error message regarding S3 Sleep. Btw the Error Message which JustinChase posted is the same like in the screenshot i have posted.

Not according to the Github Repo. For myself i also installed yesterday evening along with updates für unassigned devices etc.

I also dont have any problem by myself, and i am also on 6.8.3. Latest UD installed, just like my friend, so maybe a new install of the plugin could be the solution?

A friend of mine has the same problem and send me an screenshot with the failure.

Simple problem was that with particular Raid Adapters the normal determination if the drives are spun up or down via the I/O statistics did not work. So there was a patch with version 3.0.3 which included an activity check via hdparm, which was not reliable for me. I have reported it and it was removed. Later on it was added again with the same consequences, the HDD's seemed to be spun down in the Webif, but the script did not send the server to sleep. So i removed that check again. For me being able to determinate if the if the array is quite so now data is written to it etc. is mandatory for this plugin. The other option are nice to have. I dont know how many people are out there having the same problem like me, but based on this thread here i am not alone. I will keep my modified version of the script because i know it works.

If you download the archive from here, you should only replace what is inside the /config/plugins/dynamix.s3.sleep folder and the dynimx.s3.sleep.plg keeping your config file. Than you can reboot your machine.

From what ive know it work for many others. Maybe an editing or packaging failure?

You must calculate the MD5 hash of the new txz and add edit that in the plg. Than reboot your server and you should use the edited script. Btw i can download the attache file without any issues.

The sleep plugin is know for being defunctional for quite some people since the last update nearly two years ago. You could give this a try:

I really cant see any connection between the use of the cache drive an the stale file handle problem in my case. I just tried it. Nevertheless since i have downgraded the CIFS Protocol to v1 it seems to work again.

Added the argument yesterday evening to m mount they were still there this morning. Not a big timespan, but worth a try. I will have a look at it throughout the day.

Having the same issue since switching to unRaid 6.8.0. I have an Ubuntu 18.04 based machine which mounts 5 shares of the unRaid. Running unRaid 6.7.0 those mount where rock stable, also surviving when the unRaid goes to sleep and wakes up hours later. What i have read in some Forums actively switching the Samba Protocol version to 1.0 could solve the problem. I will try that now.

When the Debug mode shows no ethernet traffic and the drives are definately spun down than that could be a bug introduced in one of the last versions of the S3 Sleep Plugin. I think the root course was the integration of hdparm in the process of determinating if a drive is spun down. I patched that out and since then the script works as expected and reliable. I know that some people have that problem, but the script was never reverted back, althought i mentioned that problem some times here.

Yeah would be cool if this could be finally fixed. It is a small fix which i have documented here in line 233-236: https://pastebin.com/knv869Aq Matter of seconds.