• Content Count

  • Joined

  • Last visited

  1. I would not call it experience, but I did indeed do such an upgrade on a Tinkerboard last weekend. They should. Any sorts of hiccups may happen in your environment. I would suggest to: 1. Backup your data: "No backup, no pity." 2. Locate any *.dpkg-dist and *.dpkg-old files on your system and deal with them before doing anything else. 3. Read the Debian upgrade guide very carefully. Follow the references, too, especially those in "4.1. Preparing for the upgrade". 4. Execute just one step at a time, check for errors, do not continue until you are sure the action was successful. Else eliminate errors first or at least verify they really are negligible. Always keep your config files, do not let the installer overwrite them with newer versions from the packages! Deal with them during the next step. 5. Do not forget to locate *.dpkg-dist and *.dpkg-old files afterwards, diff the relating config files and either merge or otherwise handle the differences. 6. Double check the Kernel installation before attempting to reboot. No guarantees. - However, the upgrade procedure is relatively safe, if your system is in a sane state and you follow the guide precisely. One note, though: It might be more efficient and faster to backup your data and rebuild the system from scratch, that is, from a clean Armbian Buster image, and just restore your data afterwards. Consider if it is really worth the effort. (In a professional environment, I habe always denied requests to upgrade for several reasons, one of them was deployment being at least as fast or even faster than any in-place upgrades.)
  2. Apologies again, I started this thread out of eagerness and curiosity. Not to create confusion. This said, the fans should be relatively quiet once fancontrol kicked in after boot, but that depends very much on your environment. You are right though, Batch 3 fans cannot be shut off (see Wiki). I am not sure whether I understand your second question correctly, are you considering to reverse the fans (and the air flow)? Please don't. As gprovost wrote, the default direction should be the optimum for most use cases. Keeping the HDDs primarily at safe operating temperatures is what really matters in a NAS. The overview are just a few shell functions I whipped up for comparison of the two units. They have several flaws. For instance, I have used sd[a|b|c|d] names instead of proper UUIDs. The label "RPM" ist wrong, it should read "PWM" instead. And I am not sure if the temperature representation is correct. But nevertheless, here they are. Note that getCPUFreq and getCPUStats currently do not work on Buster, but on Stretch only. Add these to your non-privileged user's .bashrc and reload with "source .bashrc" or relogin. After that, simply enter "getSysStatus" on the commandline to print the overview. # Print current CPU frequency getCPUFreq() { local i freq for i in 0 1; do freq=$(cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq) printf "%s\n" "CPU $i freq.: ${freq%???} MHz" done } # Print CPU statistics getCPUStats() { local i stats for i in 0 1; do # This works, but it needs three expensive syscalls to external commands #stats="$(cpufreq-info -c $i | grep 'stats' | sed 's/,/;/;s/:/: /g;s/\./,/g')" # Same, but reduced by one stats="$(cpufreq-info -c $i | \ awk '/stats/{gsub(",",";");gsub(":",": ");gsub("\.",",");print}')" # Cut front and end from string; this could be done in awk, too, but the # resulting expression would be long and hard to decipher for non-awk users. # Using shell internal string functions should not be that expensive, either. stats="${stats#*: }" stats="${stats% *}" # Finally, print the resulting string, nicely formatted printf "%s\n" "CPU $i stats: ${stats}" done } # Print system fans speed getFanSpeed() { local i j=3 speed for i in 10 17; do speed=$(cat /sys/devices/platform/j$i-pwm/hwmon/hwmon$j/pwm1) printf "%s\n" "Fan J$i RPM: ${speed}" ((j++)) done } # Print SoC temperature getSoCTemp() { local temp=$(cat /sys/devices/virtual/thermal/thermal_zone0/temp) printf "%s\n" "SoC core temp.: ${temp%???},${temp: -3}" } # Print ambient temperature getAmbientTemp() { local temp=$(cat /dev/thermal-board/temp1_input) printf "%s\n" "Ambient temp.: ${temp%???},${temp: -3}" } # Print temperature of all HDDs getDriveTemps() { local i temp for i in /dev/sd[abcd]; do temp=$(sudo /usr/sbin/smartctl -a $i | awk '/^194/{print $10}') printf "%s\n" "$i temp.: ${temp}" done } # Print current power mode status of all HDDs getDriveStates() { local i state for i in /dev/sd[abcd]; do state="$(sudo /sbin/hdparm -C $i)" printf "%s\n" "$i state: ${state##* }" done } # Print system status getSysStatus() { # printf "\n" # getCPUStats # printf "\n" # getCPUFreq printf "\n" getFanSpeed printf "\n" getSoCTemp getAmbientTemp printf "\n" getDriveTemps printf "\n" getDriveStates }
  3. @devman: Good point. And I think you are right. Out of curiosity I have placed another sensor in the case, directly beneath the disks. It is not very precise though, but I thought it might at least give a hint. I have no others at the moment (HomeMatic IP HmIP-STH). @gprovost: Thanks for the clarification on ECC! That is good to know - and also very reassuring. Regarding the delta I think it was a temporary glitch. And yes, I agree that the HDD temps should be the main point. The new numbers are below, and they support your configuration. Come to think of it, I am not sure if I would like to see the HDD temps rise above another five degrees or so. The last summers were hot here and room temperature could easily climb above 30°C. I think ich will reverse these reversed fans again. But it was at least fun to test! Yes, I like the Helios4 for it's possibilities. - By the way, when you announced that you would ship each order with an OLED display (as I read it), I meant to ask for another one for the second unit. I was more than happy to learn that each one would be shipped with it. So, identical hardware. Small things, but they look cool, especially in the dark. 12 hs idling: Room temperature: 21,70°C Humidity: 55% Unit #1: Unit #2: Fan J10 RPM: 74 Fan J10 RPM: 39 Fan J17 RPM: 74 Fan J17 RPM: 41 SoC core temp.: 48,456 SoC core temp.: 42,267 Ambient temp.: 34,812 Ambient temp.: 31,250 Case: 24,10 Case: 24,20 Humidity: 48% Humidity: 48% /dev/sda temp.: 23 /dev/sda temp.: 23 /dev/sdb temp.: 23 /dev/sdb temp.: 24 /dev/sdc temp.: 23 /dev/sdc temp.: 24 /dev/sdd temp.: 23 /dev/sdd temp.: 25 /dev/sda state: standby /dev/sda state: standby /dev/sdb state: standby /dev/sdb state: standby /dev/sdc state: standby /dev/sdc state: standby /dev/sdd state: standby /dev/sdd state: standby 30 mins. after reboot: Room temperature: 22,00°C Humidity: 54% Unit #1: Unit #2: Fan J10 RPM: 74 Fan J10 RPM: 52 Fan J17 RPM: 76 Fan J17 RPM: 49 SoC core temp.: 49,408 SoC core temp.: 44,171 Ambient temp.: 35,500 Ambient temp.: 32,500 Case: 23,80 Case: 25,10 Humidity: 50% Humidity: 49% /dev/sda temp.: 27 /dev/sda temp.: 29 /dev/sdb temp.: 27 /dev/sdb temp.: 29 /dev/sdc temp.: 27 /dev/sdc temp.: 30 /dev/sdd temp.: 27 /dev/sdd temp.: 31 /dev/sda state: active/idle /dev/sda state: active/idle /dev/sdb state: active/idle /dev/sdb state: active/idle /dev/sdc state: active/idle /dev/sdc state: active/idle /dev/sdd state: active/idle /dev/sdd state: active/idle
  4. I see. But does the Armbian Kernel actually make use of it? I am curious, because I know how to check for ECC functionality on arch x86, but unfortunately not on arm. Air Flow: My apologies for being too focused on my own narrow use case. A bit naive and unprofessional an approach, I guess. I really didn't think of units placed in cupboards or other locations where dust and waste heat might cause trouble (mine are in an open 19" rack). You were right, though, the first approach basically corresponded to a reversed fan plate. I have since changed that back to the original position, but with reversed fans. So they are now mounted exactly as shown in the Wiki, but with the labels facing inwards. As mentioned, that required slightly longer screws. I have used those from a Lian Li OF-01B anti-vibration fan mounting kit that was lying around. This configuration shows even greater differences. Currently I see a 10°C divergence between the SoCs with a 3°C difference in ambient temperature. No relevant changes in disk temps. Now, I don't trust these numbers myself, so I will repeat the above tests at the weekend when there is more time and report back in this thread. Fan noise was never the trouble, by the way; the default fancontrol settings were not changed. These lower fan speeds are just a result of the case interior keeping cooler. I think your settings are fine. Keeping the disks within their optimal temperature range is far more important, and in my environment the fans are barely audible in normal operation.
  5. 1. Question: How do I check that ECC is really active? 2. Possible Kernel issue: The Debian Buster image's Kernel seems to lack CPU frequency info settings: "cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: No such file or directory". How can that be fixed? 3. Possible assembly issue: I think the air flow through the case should be reversed. Testing scenario: two units about 0,5 m apart in the same location. One unit assembled as shown in the Wiki, the second one assembled with reverse fan direction. First unit equipped with WD40EFRX-68N32N0 (3 platters), second one with the older WD40EFRX-68WT0N0 (4 platters). Because of that, the second unit was expected to run slightly warmer. First test after 12 hs idling, second test 30 mins. after a reboot. As you can see, the unit with the reversed air flow always stays cooler even with lower fan speeds. In idle, there is a whopping 5.72°C difference in SoC temperature and a 2.56°C difference in ambient temperature. Fans speed in second unit reduced by nearly 36%. Disk temperatures are all pretty similar. After reboot, there is a still a 3.80°C difference between the SoCs and a 1.94°C difference in ambient temperature. Fans speed difference is nearly 29%. Disks in the second unit run warmer, but are now within their optimal temperature range between 30°C and 40°C. (Beyond that, failure rates rise steeply even if WD40EFRX are rated for up to 60°C.) Of course, behaviour under load remains to be seen. I cannot test that at this early stage. But even with measurement inaccuracies taken into account I still think the fans should be mounted the other way round. That would require either longer screws, silicone anti-vibration mounts or you would have to do with the fans mounted on the other side of the plate with the ribbon cables threaded through one of the holes, as I have done for this test. Thoughts/comments? 12 hs idling: Unit #1: Unit #2: Fan J10 RPM: 68 Fan J10 RPM: 44 Fan J17 RPM: 74 Fan J17 RPM: 47 SoC core temp.: 49,408. SoC core temp.: 43,695 Ambient temp.: 34,687. Ambient temp.: 32,125 /dev/sda temp.: 23 /dev/sda temp.: 23 /dev/sdb temp.: 23 /dev/sdb temp.: 23 /dev/sdc temp.: 22 /dev/sdc temp.: 23 /dev/sdd temp.: 22 /dev/sdd temp.: 25 /dev/sda state: standby /dev/sda state: standby /dev/sdb state: standby /dev/sdb state: standby /dev/sdc state: standby /dev/sdc state: standby /dev/sdd state: standby /dev/sdd state: standby 30 mins. after reboot: Unit #1: Unit #2: Fan J10 RPM: 76 Fan J10 RPM: 52 Fan J17 RPM: 74 Fan J17 RPM: 55 SoC core temp.: 49,408. SoC core temp.: 45,600 Ambient temp.: 35,312. Ambient temp.: 33,375 /dev/sda temp.: 26 /dev/sda temp.: 29 /dev/sdb temp.: 26 /dev/sdb temp.: 30 /dev/sdc temp.: 26 /dev/sdc temp.: 31 /dev/sdd temp.: 26 /dev/sdd temp.: 30 /dev/sda state: active/idle /dev/sda state: active/idle /dev/sdb state: active/idle /dev/sdb state: active/idle /dev/sdc state: active/idle /dev/sdc state: active/idle /dev/sdd state: active/idle /dev/sdd state: active/idle