Jump to content
XPEnology Community

Leaderboard

Popular Content

Showing content with the highest reputation on 07/07/2020 in all areas

  1. Bonjour, En root, via ssh (et sudo je pense, je me connecte en root directement via une clef donc je ne passe pas par un copte admin) : Commande : netstat -lataupen Il y a 2 a qui sont redondant dans les options de la commande, mais ça donne un nom facile à mémoriser pour "espionner" tout ce qui est ouvert en ports, le "n" à la fin permet d'afficher le numéro du port au lieu du nom. De mémoire, a pour voir toutes les sockets (même non connectées), t pour tcp, u pour udp, l pour la liste, p pour le nom du programme attaché. Jacques
    2 points
  2. I recently installed Xpenology on a Terramaster F4-220 I picked up during the holiday sales that were going on. I noticed the hard drives were consistently operating at a very high temperature (50+ C while idle) so I decided to investigate how to control the fans. I had read elsewhere there is some BIOS option to drive the fans faster, but lacking the VGA dongle to get into the BIOS I figured I'd investigate how to control them from Linux. So I discovered the hardware contains an IT8772E chip for which Google helpfully brings up this datasheet: https://master-chip.ru/files/e0ec6325-b20e-079c-f0ce-275a3ec60f51/IT8772E-ITE.pdf I noticed that there is already a kernel driver for this chip, but since I only needed very limited capabilities (just the ability to write the fan PWMs) I decided to just write a custom script to do this. I'm sharing it here so others can take advantage of it. I'm guessing it wouldn't be hard to also drive the LEDs to the right colors as well but I haven't spent time on that since I never look at the LEDs anyway. The basic flow of the code is: Initialize the IT8772E chip Write a default PWM value for the fans Read the max hard drive temperature and use a PID loop to calculate a new PWM value to drive the max hard drive temperature to some setpoint After playing with the PID values for a few days I concluded that just using a P value was sufficient to give decent behavior so I just left kp = 1, ki = kd = 0. I just modified the script to make all of these things overridable in case someone wants to play around with it further without having to recompile. With defaults I find it settles to reasonable values in about 30 minutes. By default the script uses a setpoint of 37 C but again this can be overridden. I chose this after looking at various suggestions online, it seems 30-40 C is the safest range to maintain for average temps in terms of drive failure rate, so 37 C should give some buffer in case of sudden spikes in utilization that PID doesn't react to quickly enough. My argument parsing is really simple, you can use ./fancontrol -h to see how to use the script. Here are some sample uses: ./fancontrol (default behavior) ./fancontrol -h (print out usage info) ./fancontrol 1 40 (enable debug logging, setpoint = 40) ./fancontrol 0 37 255 (use the maximum PWM value initially before entering the PID loop) ./fancontrol 0 37 150 10 50 80 0 0 0 0 (use PWM value 150 initially and disable PID by setting all coefficients to 0, this would be like hard-coding the PWM to 150 forever) Anyway, I hope other Terramaster users find this useful. I suspect this will also work on similar Terramaster NASes that use the same chip for fan control but I have only tested on the F4-220 since that's what I own. I've attached the cpp source and a binary built for x86_64 running DSM 6.2 using Synology's build environment (ds.x64-6.2). Some side notes: The synostorage daemon already reads drive temperatures and reports them in /var/run/synostorage/disks/sd[abcd]. I initially used these to drive my code but later realized these values may be updated very infrequently (as in many minutes) so I decided to poll via smartctl. I still rely on the disks listed in /var/run/synostorage to know which drives to query. I don't read the CPU temp (or any other sensors). I think keeping the drives at 40 C or below will likely be a stronger constraint on fan speed than CPU usage, but if you expect heavy CPU usage at times when there isn't heavy storage utilization (unlikely for a NAS) then this may not be what you want. I chose an MIT license for the source I don't really intend to maintain this long term except for myself but if people have suggestions let me know and I can try to tackle them. You can run this at boot time using "Task Scheduler" fancontrol fancontrol.cpp
    1 point
  3. Ну Аллилуйя ......))) Рад за ваш успех
    1 point
  4. there are no raid drivers for intel or amd but there are raid drivers for the lsi controllers in the driver set (megaraid, megaraid_sas) but you will not have muck info or control without the proper tools that are not part of dsm, the preferable method is still to have single disks in dsm and do raid with mdadm the way dsm does it, you might spare 60-80 bugs but if it comes to trouble with disks or controller its much harder to identify a problem or replace the controller, with mdadm you can use any controller, even a cheap multiport ahci controller i don't see any downsides with 6.2.x or in particular with 6.2.3 when comparing with 6.1.x, it gets all the latest updates and packages
    1 point
×
×
  • Create New...