Forum des NAS

Tous les fabricants de NAS réunis sur un forum unique : Asustor, Qnap, Synology...

Comment choisir le bon matériel pour fabriquer son propre NAS
#105429
Montage du "NAS".
- Excellent boitier Boitier Fractal Design Meshify 2, j'y ai casé 11 disques 3.5" quasiment l'un sur l'autre,
et ventilés par 3x14 cms 1000 tours/mn situés à 3 cms des disques. Vraiment bien ce boitier, même si j'ai
dû repartir au bureau rechercher encore plus de visserie, merci le télétravail. J'aurai pu y mettre jusqu'à
15 3.5" : 2 attachés au dessus, 9 sur l'attache principale, 2 x 2 en dessous à côté de l'alim.
- pas de souci spécifique sur le montage; j'ai mis 2 photos, je précise que le câblage est provisoire, c'est
un peu salopé, pas taper!
- une boulette de taille: j'ai pris 2 SilverStone CPS05-RE comme câbles SSF-8643 / SATA. Dommage! Après
qqs heures de galère, je viens de me rendre compte que les câbles 8643 / SATA sont directionnels, et que
j'avais réussi à commander le sens SATA -> 8643. Bon, amazon est mon ami...
Une mise à jour du bios de la B550E, une petite install en WIndows histoire de descendre les voltages et de
monter la mémoire à 3600 Mhz, puis j'attaque l'install Linux et les tests de perfs.
Pièces jointes
gauche.jpg
gauche.jpg (291.05 Kio) Consulté 292 fois
droit.jpg
droit.jpg (488.2 Kio) Consulté 292 fois
#105616
Optimisation processeur AMD.

Note: tous les chiffres donnés ici sont faits avec une mémoire à 2666 Mhz C14.
L'optimisation mémoire fera l'objet du message suivant. De toute façon, Cinebench R20 n'est que (très) peu sensible
à la vitesse mémoire.

-> installer un windows avec tous les drivers, dont les AMD les plus récents.
-> installer O&O ShutUp 10 et tout activer, histoire d'être moins ennuyé par Windows.
-> installer Cinebench R20 et HWInfo64.

Ensuite, dans le BIOS, il faut diminuer par offset le voltage du processeur, habituellement entre -0.06 et -0.12V,
le plus souvent un peu en dessous de 0.1 Volt.
Pourquoi ? Parce que la descente du voltage du processeur descend la consommation, donc la température processeur,
ce qui permet à l'algo d'AMD d'augmenter les fréquences du processeur durant les calculs, puisque sa fréquence
est indexée sur la température et les limites de consommation.
Je fais le test CineBench R20 24 threads avec le PBO activé sur Enable, donc avec les limites de la carte mère, ou
si besoin en Manuel avec des limites maxi cohérentes (255 & 255 Ampères, et 384 Watts pour les PPT, TDC et EDC).
===> ATTENTION: cela suppose une BONNE carte mère, une BONNE alimentation, un BON refroidissement processeur!
La conso d'un 3900X est alors d'environ 135 watts pour une température de 70 à 75°C (ventilos à fond); la fréquence
est proche des 4.1 Mhz sur tous les coeurs.
Après quelques tests de -0.08V à -0.12V, le meilleur score CineBench R20 est vers 7375 pour -0.09375V sur mon processeur.

Ensuite, je désactive non seulement le PBO (complétement inutile ce truc) mais aussi le Core Performance Boost,
autrement dit j'interdis à mon processeur tout dépassement de sa vitesse optimale constructeur, soit pour le
3900X une fréquence de 3800 Mhz. Pourquoi ?
Parce qu'après je recommence les mêmes tests - plus par sécurité qu'autre chose -, et aboutit à l'optimum de
Cinebench R20 sur un 3900X à 3800Mhz: 6796, également avec un offset de voltage CPU de -0.09375V.

Pour un serveur, et même pour une machine de jeux tant que les jeux sont récents donc multithreads, ce réglage est
bien meilleur que la course à la plus grande vitesse possible, à la fois pour la stabilité machine mais aussi pour sa
longévité. Et aussi pour vos oreilles (ventilo qui tournent moins vite) et pour la planète et votre facture d'électricité
(conso processeur).

Pour un 3900X, Cinebench R20, avec -0.09375 Volts en offset sur le voltage processeur:
- à fond SANS overclock, mais avec Core Boost et PBO: 7373, 70 à 75°, 135 watts, soit 7373 / 135 = 54 points Cinebench
par watts;
- à 3800 Mhz (sans CoreBoost, sans PBO): 6796, 52°, 86 watts, soit 6796 / 86 = 79 points par watts.
Ou encore 20 degrés de moins, 49 watts de moins, soit 36% de conso en moins, pour une perte de puissance de calcul
dans un benchmark processeur [donc dans le pire cas possible!] de 7.8%.

Et en plus c'est facile à vérifier de façon théorique : 4.1 / 3.8 - 1 = 7.8%.
300 Mhz de plus qui coûtent 49 watts et 20°, c'est vraiment pas utile!

Donc faites plaisir à la planète, à vos oreilles, à votre machine (chaleur processeur = pas bien), et enlevez ces gadgets
que sont le PBO et le Boost Core, particulièrement pour un serveur qui tourne tout le temps en multithreads. Même sur
une machine de gamer (avec des jeux récents donc multithreads), cela ne sert qu'à hauteur de 0 à 5% max sur le framerate.
En moyenne 1 à 2% d'ailleurs, car le GPU fait bien plus de boulot que le CPU.

Prochain message: comment optimiser sa mémoire sous Zen 2 de façon intelligente - ou comment atteindre 3600 Mhz C18
sans le moindre overclock et overvoltage, en tout cas pour la dizaine d'AMD Zen 2 que j'ai optimisée en 1 an.
#105634
Optimisation mémoire.

NB: tout ce qui est présenté ici est approximatif!

Pourquoi optimiser la bande passante mémoire ? Parce que la mémoire DDR4 équipe nos
machines depuis près de 15 ans avec la même bande passante, alors que les processeurs
entre temps sont passés de 4-6 à 16 coeurs. Résultat: une famine mémoire lorsque les
coeurs fonctionnent sur des zones mémoire séparées.

Que doit-on optimiser, la bande passante ou la latence (temps d'accès à une donnée) ?
Vieux débat totalement obsolète. La latence est une caractéristique de la mémoire, et
est d'environ 8 à 11 nano secondes pour la DDR4. Par contre, la bande passante est
une combinaison des caractéristiques mémoire, processeur, architecture, etc. Donc il
est largement préférable d'abord d'optimiser la bande passante, puis d'adapter les
réglages de la mémoire, qui sont non en nano secondes mais en périodes (inverse de la
fréquence) dans le BIOS.
Ex: 3600 Mhz DDR4 -> période = 0.555 ns (la DDR4 est accédée sur front montant et descendant)
-> nb de périodes entre 14 et 20 soit une latence entre 7.7 ns et 11.1 ns.

Par défaut sur une machine classique, la DDR4 utilise la norme (JEDEC) 2133 ou 2666 Mhz,
ce qui avec un nombre pair de barrettes sur une architecture Zen donne un débit maximal
théorique respectif de 34 et 42 GB/s, soit en pratique un maximum de 5% de moins:
32.4 GB/s et 40.5 GB/s.

La technique que je présente rapidement ici permet de passer suivant l'architecture Zen X à :
Zen1 : 3200 Mhz / 49 GB/s réel
Zen1+ : 3400 Mhz / 51.6 GB/s,
Zen 2 : 3600 Mhz / 54.7 GB/s,
Zen 3 : 3800 Mhz / 57.7 GB/s.
Ces chiffres représentent ce qu'AMD donne comme sa bande passante mémoire maximale "stable"
avant de devoir overvolter la machine, ce que je ne fais jamais en tant que professionnel.

Il existe énormément de méthodes sur le web pour optimiser sa mémoire, mais elles ont
tous le même défaut: c'est bien trop long & compliqué, souvent pas fiable, avec le même
défaut majeur: tenter d'atteindre le maximum possible de bande passante. Sauf que cela
ne sert à rien de s'acharner pour gagner 1 à 5 % max en y passant des heures et aboutir à un
résultat instable. Cela m'a toujours fait rire de lire "votre machine sera stable si vous
arrivez à faire tourner le benchmark tagadatsointsoin durant 24 ou 48 heures".
Parce que c'est faux. A un moment donné, vous aurez plus d'humidité, un condensateur un peu
défaillant, une température trop haute ou basse, une nanocoupure, un voltage fluctuant sur
votre ligne EDF, et cela plantera. Donc il faut optimiser la bande passante de façon
raisonnable, pour une bonne fiabilité et surtout rapidement pour ne pas passer des jours
à mettre tout au point.

Choix de la mémoire: prendre 2 (ou 4) modules mémoires avec un refroidisseur quelconque,
tant qu'il y en a un et que cela rentre sous votre refroidisseur processeur. La marque
importe peu; cherchez plutôt le moins cher possible et rajoutez 15 à 20% pour avoir
une qualité correcte. Privilégiez les modèles que vous pouvez trouver en stock chez
plusieurs vendeurs (LDLC, Amazon, etc); vous éviterez les fins de stock et pourrez comparer
les prix. De toute façon, c'est surtout le fabriquant de la chip (le "die") qui compte, donc
Samsung, Hynix ou Micron; chez ces fabriquants, il y a des références; dans ces références
il y a des révisions, et chacun a des perfs légèrement différentes. Savoir ce que le
fabriquant de la barrette mémoire vous vend comme die est la plupart du temps impossible
donc inutile; et même comme cela il y a de moins en moins de "mauvais" die.
Ne vous prenez pas la tête, ça ne vaut pas le coup.

Installez vos barrettes si possible le plus près du processeur, en channels A et B (donc
A1&B1 ou A2&B2). Vérifiez que vous bootez en windows. Mettez à jour votre bios,
habituellement dans la dernière version pour profiter de la dernière version de l'Agesa
disponible, en priant qu'elle ne soit pas buggée...

Commencez par installer sur Windows Taiphoon Burner & l'excellent Ryzen Dram calculator.
Installez aussi le shareware AIDA64.

Ensuite, la partie ennuyeuse du Bios. J'ai ici une asus B550-E, mais cela fonctionne sur
tous les bios (sauf Dell & HP et consorts; prenez une vraie carte mère!).
Régles du bios:
- on met en Optimisé; si pas dispo on garde le défaut sauf si contre ordre, sinon pas touche!
- si on a un chiffre en %, mettre toujours le plus faible, habituellement 100%!
- tout ce qui est Spectrum: desactivé;
- on ne touche pas aux voltages sauf si contre ordre!

Voici mes réglages différents des réglages par défaut:

Memory Frequency: *VOIR PLUS LOIN*
FCLK Frequency: toujours la moitié de la fréquence mémoire! Eventuellement Auto.
Performance Bias: None - ne jamais se fier aux "optimisation de perfs" de la carte mère.

Précision Boost Overdrive (menu):
PBO Fmax Enhancer: Disabled
Précision Boost Overdrive: Disabled
Platform Thermal Throttle Limit: Manual, 85°C

DRAM Timing Control (menu)
Réglages de la mémoire (tRL/CAS, tRCD, tRP...) : *tout auto pour l'instant*
Réglages de l'accès mémoire (Zen1 à Zen 3):
ProcODT: 40 à 43 (cette valeur par défaut fonctionne de Zen1 à Zen2; pas assez testée sur Zen3).
Cmd2T: 1T
Gear Down Mode: *VOIR PLUS LOIN*, mais au début Disabled
Power Down Enable: Disabled
RttNom: RZQ/7 (le minimum supérieur à zéro en fait) si 4 barrettes; sinon disable avec 2.
RttWr: RZQ/3 (80 Ohms)
RttPark: RZQ/1 (240 Ohms)
Mem*Setup: auto, auto, auto
MemCadBus*Stren: tous à 24 Ohms sauf MemCadBusAddrCmdDrvStren à 20.

NB: ces réglages peuvent être affinés avec Ryzen Dram calculator, une fois connu par
Thaiphoon Burner le type de die de votre mémoire (Hynix *FR, Micron x-Die, etc). Mais
ne vous fiez que peu aux valeurs des tRL, tRCD, etc. de la mémoire: ce n'est que
statistique, au mieux!

DIGI+ VRM:
Attention: les chiffres derrière le mot Level concernant le Load Level calibration pour
contrer l'effet Vdrop sont inversés entre Asus d'un côté et MSI & Asrock de l'autre.
Autrement dit, Level 1 chez Asus a un effet de calibration minimal, mais maximal chez MSI
et Asrock!
Dans le doute, laissez sur Auto. Il faut bien garder en tête que les alimentations modernes
DE QUALITE et suffisamment dimensionnées compensent l'effet Vdrop elles-mêmes par leur
réserve de puissance, ET que les processeurs récents s'y adaptent aussi! Donc l'utilisateur
standard ne doit jamais toucher à ce genre de réglage.
Chez tous les constructeurs, auto est normalement le level minimum.
Aparté: l'alimentation d'un PC est à mon avis son composant le plus important. Ne lésinez
jamais dessus! Cherchez dans google "PSU Tier List". Fin de l'aparté.
Pour les réglages des VRM, mettez 100% (le minimum), Optimised, et auto pour la calibration.
Autrement dit ne poussez JAMAIS les VRM, cela ne sert à rien, c'est l'inverse, car la
qualité du signal d'alimentation descend dès que les VRM sont (trop) sollicitées!

Voltages de la machine:
VDDCR CPU Voltage: offset, -0.09375V, cf mon message précédent.
VDDCR SOC Voltage: manual, 1.025V. C'est la valeur par défaut et cela doit le rester!
DRAM Voltage: 1.35V. C'est la valeur des réglages XMP et l'optimum constructeur!
VDDG (CCD et IOD, >= Zen 2): 0.9V. C'est la valeur par défaut et cela doit le rester!
CLDO VDDP: 0.854V, ou 0.855V, ou 0.85V dans cet ordre.
Les autres voltages restes en Auto.

Dans l'AMD CBS (ou PBS):
Core Performance Boost: perso, je met sur Disabled; vous pouvez le laisser sur Auto;
Memory interleaving size (DF Common Options/Mémory Adressing): 512 Bytes, que je pense
aussi être le défaut;
Memory Clear: Disabled;
BankGroupSwapAlt (si vous avez): Enable, Adress Hash Bank 2 ColXor non modifié (3F8);
Si vous n'avez pas le précédent, BankGroupSwapAlt: Enabled, sinon Disabled.
Important si vous l'avez: DDR4 Common Options/Phy Configuration/PMU Training):
DFE Read Training: Enabled (ou Auto si pas);
FFE Write Training: Enabled (ou Auto si pas);
PMU Pattern Bits Control: Manuel, mettre la valeur numerique hexadécimale "A"

=========================================================================

Une fois ceci fait, toujours dans le bios, recherchez dans les menus constructeurs
un moyen de sauver votre bios; chez Asus c'est le menu Tools/Profils Utilisateur.
Sauvegardez TOUJOURS votre bios à chaque modification, car en cas de plantage,
vous le relirez à partir de ce menu.

Assurez-vous d'avoir la bonne méthode pour effacer le BIOS de votre machine;
habituellement un bon tournevis ou une paire de ciseaux pour faire contact 10
secondes sur le bon cavalier de votre carte mère *avec l'alim débranchée du
220V!* suffit. Certaines cartes mères ont un bouton pression à l'extérieur
pour effacer le BIOS, consultez votre manuel.
NB: une bonne frontale est utile si vous êtes mal éclairé!

=========================================================================

Voilà, maintenant la méthode, très simple, bien bourrin!

Etape 1:

Vous allez modifier les valeurs de memory frequency et FCLK frequency de façon
décrémentale, à partir des optima réalistes qui sont:
3800/1900 (Zen3), 3600/1800 (Zen2), 3400/1700 (Zen+), 3200/1600 (Zen1).
Vous sauvegardez votre BIOS et bootez. Si cela ne boote pas (machine plantée), resettez
le bios, revenez dans le bios (qui est en défaut), relisez le bios que vous avez sauvegardé,
diminuez de 133/66 les valeur des fréquences, resauvez le bios, et recommencez jusqu'à
ce que vous bootiez.

Lancer alors un Memtest avec Ryzen Dram calculator. Si cela marche (1 minute max de test!),
l'étape 1 est finie. Si il y a erreur de mémoire, recommencez avez 66/33 de moins.

Si vous avez un mauvais résultat, style plus de 400/200 Mhz en dessous de l'optimum,
ne vous découragez pas: recommencez avec l'option Gear Down Mode mise à Enabled.
Vous devriez avoir de meilleur résultats. Si vous obtenez les mêmes, préférez
Gear Down Mode mise à Disabled.

Tout le reste des manips des autres méthodes (modifiez les voltages, procODT, et
autres) sont tout simplement inutiles dans l'immense majorité des cas!

Etape 2:

Vous avez maintenant la fréquence mémoire. Il faut l'affiner avec les réglages
au moins primaires de la mémoire elle-même. Les 3 réglages cruciaux sont le tRL ou CAS,
le tRCD et le tRP; un cas particulier est le tRFC. Vous allez faire exactement la même
méthode que précédemment, en procédant de la même façon pour chacun de ces 4 réglages,
1 par 1 et dans cet ordre:

1. tRL ou CAS ou latency: si vous avez activé le Gear Down Mode, seuls des nombres
pairs peuvent être utilisé. L'optimum est habituellement 18 pour 3800 ou 3600 Mhz, et
16 pour 3400 ou 3200 Mhz. J'ai toujours obtenu cet optimum sur toutes mes machines;
parfois 16 en 3600 sans le moindre overvoltage.
Pour le NAS, j'ai obtenu 18 à 3600 Mhz pour mon Zen2/3900x.

2. Un fois le CAS stable, le tRCD, qui se décompose souvent en tRCDRD et tRCDRW. Cette
valeur est habituellement +1 à +4 par rapport au tRC. Toutefois, sur le NAS,
j'ai dû le monter à 23, soit +5, la valeur la plus élevée que je n'ai jamais utilisée. Attention,
cette valeur est la plus difficile à stabiliser d'après mon expérience.

3. Le tRP, ou RAS# PRE time, habituellement +4 (fiable mais médiocre) à +2 (bon mais
risqué) par rapport au CAS. 22 est la valeur que j'ai mise pour le NAS par sécurité.

4. Exceptionnellement, j'ai dû régler le tRFC de façon fine sur la mémoire de mon NAS.
Le tRFC est le temps nécessaire en périodes de la mémoire pour rafraichir ladite mémoire.
Cela dépend complétement de la nature du Die; normalement le temps de rafraichissement
maximal est de 350 nano secondes. Donc pour une fréquence mémoire de 3600 Mhz (en fait
1800 car les opérations de la DDR4 sont en front montant ET descendant), cela donne
tRFC (ou tRFC1) = 350 * 1.8 = 630.
Normalement, tRFC2 et tRFC4 ne sont pas utilisés par AMD mais toutefois présents dans
le BIOS; leur formule est
tRFC2 = tRFC1 / 1.346, donc pour moi 468,
tRFC4 = tRFC2 / 1.625, donc pour moi 288.

Cet excellente image donne à la fois le temps tRFC dit maximal pour un die donné et
la table de calcul des tRFC par rapport au temps en nano-secondes versus la fréquence
mémoire:

Code : Tout sélectionner
https://preview.redd.it/89tv3ctbfp251.jpg?width=1077&format=pjpg&auto=webp&s=ba1ee3c34d2a0310150278c9aa3cf9791677fc59

Dans mon cas, comme j'ai 2 barrettes de 32 GB, j'ai forcément des Die 16 Gbits
récents (32 GBytes = 8 Dies de 16 Gbits sur chaque face de la barrette), donc ayant un
tRFC médiocre. J'ai de la Hynix *JR 16 Bits, donc avec un tRFC de 350 ns. En fait, j'ai dû
monter mon tRFC à 380 nano secondes, soit à 3600 Ghz une valeur énorme de tRFC1 = 684,
et modifier tRFC2 et tRFC4 en conséquence.

Astuce: si votre machine ne s'éteint pas du tout après un réglage de BIOS (pas de
claquement caractéristique de l'alimentation qui s'éteint et s'allume) c'est très
souvent le tRL/CAS ou les tRFC* qui sont trop faibles.

5. Les réglages secondaires de la mémoire: bien moins importants, passez-y qqs minutes
toutefois.
tRAS (ou RAS# ACT time) = tRC + tRCD + [-2 à 2], je conseillerai +1.
tRC = tRAS + tRP, éventuellement -1 ou +1; je conseillerai +0.
tRRDS et tRRDL: habituellement 6 et 8, éventuellement 5 et 7, voir 4 et 6 pour une fréquence
< 3200 Mhz.
tFAW: il est inclus entre tRRDS * 4 et tRRDS * 8, je conseillerai donc vers 30 environ.

Les autres tXXX sont insignifiants, laissez les à Auto.


Enfin, relancez cette fois 10 (30 pour les anxieux) minutes un Memtest pour vérifier que vous
avez aucune erreur. Au délà, c'est peu pertinent.

Pour terminer, lancer le test de mémoire de AIDA64. Les 2 valeurs intéressantes sont la
lecture mémoire: 3600 Mhz = ~55 GB/s (Zen2), et la latence, qui dépend du tCL/CAS:
sans overvoltage, elle doit être entre 68 et 78 ns, cette fois quelque soit la fréquence
de la bande passante mémoire. Sur mon NAS, je suis à 72 ns.

Fini! En temps normal, avec un peu d'habitude, cela me prend 1 à 2 heures, et c'est stable
depuis 4 ans, incluant un threadripper 1950X (3333 Mhz et ~100 GB/s).


Tout commentaire apprécié.

Avatar de l’utilisateur
par EVOTk
#105647
Shad a écrit : 19 juil. 2021 17:53 Difficile de dire quelque chose, tes connaissances sont bien au-dessus des miennes, et mes exigences tout autres.
Néanmoins merci pour tes retours !

je n'aurai pas dit mieux :plusun::bounce:

#105652
Shad a écrit : 19 juil. 2021 17:53 Difficile de dire quelque chose, tes connaissances sont bien au-dessus des miennes, et mes exigences tout autres.
Néanmoins merci pour tes retours !

Tiens, à titre indicatif, quelles sont tes exigences ? Plus de fiabilité ou plus de puissance ? Ou ne pas s'enquiquiner avec
quelque chose qui n'apporte finalement que 5 à 15% de perfs réelles en plus pour quand même un boulot bien technique
et assez délicat ? C'est vrai que pour un NAS, c'est pas flagrant, mais les calculs de parité d'un ZFS RAIDZ-2 (RAID6 donc)
peuvent être extrêmement coûteux, surtout si en sus les données sont cryptées, ce qui est requis; tenir du 10 Gbit/s
réseau avec des clients multiples (voir 40 Gbit/s pour une évolution prévue en RJ45 catégorie 8) nécessite une mémoire très
performante.
Une seule caméra d'acquisition en 2160p 60 FPS (un bon smartphone de 2020 fait cela!) avec un encodage quasiment sans
perte (pas RAW!) peut demander un débit de 20 à 100 MB/s actuellement, et on en a besoin de parfois plus d'une douzaine
pour filmer un seul opérateur (mains, visage, posture corporelle, etc) sur différents angles simultanément.
Avec du 9+2 disques mécaniques, j'espère atteindre les 1 à 1.5 GB/s en écriture soutenue, c'est finalement pas beaucoup pour
ces exigences et avec un amortissement financier de 3 à 5 ans pour ce petit NAS.
Je ferai qqs tests sur l'intérêt de la vitesse mémoire en Linux ces prochaines semaines quand je rechercherai les bottlenecks
du NAS - j'ai pas encore reçu mes 2 câbles SSF-8643 / SATA :cry:

Avatar de l’utilisateur
par Shad
#105653
Du tout, j'aime avoir un serveur ennuyeux que je peux oublier.
J'utilise du coup une Debian classique pour sa stabilité.
Mon utilisation :

  • Serveur multimédia : j'utilise le GPU intégré pour transcoder les fichiers pour ma famille (20 Mbps en upload chez moi, donc transcodage dans quasiment tous les cas ne serait-ce que pour le débit).
  • Hébergeur de services via Docker : Gestionnaire de mot de passe, Authentification 2FA, Snapcast, Adblock, Synchronisation de données, etc...
  • Seedbox : sur un disque dédié hors grappe RAID, vu le nombre de lecture/écriture constante il va plus vite s'user que les autres.
  • Virtualisation : KVM en CLI et via Virtual Manager.

Mise en place de tests S.M.A.R.T. réguliers pour m'assurer de la santé du système, monitoring sur 14j via le combo Telegraf, InfluxDB et Grafana.
J'utilise BorgBackup pour sauvegarder les données de mes conteneurs et mes fichiers de config dans /etc, /home et /root sur mon NAS Synology DS918+.

Je n'ai aucun besoin de débit supérieur au gigabit, car on est 2 à 3 personnes à l'utiliser et j'utilise déjà LACP.

Le BTRFS n'a pas les mêmes exigences matérielles que ZFS (1 Go de mémoire par To de stockage si je me souviens bien). Ma prochaine étape est d'apprendre à jouer avec les commandes BTRFS subvolume et snapshot, pas encore le temps de m'y pencher...

Ma config c'est un i3 9ème génération, 16 Go DDR4 (pour pouvoir faire tourner 2-3 VM sans handicaper l'hôte).

Ce qui m'intéresse dans ton retour c'est la question du réglage du voltage et l'annulation du mode turbo, même en plein transcodage j'ai l'impression qu'il n'est pas employé.
A la base je voulais un modèle de processeur basse consommation, mais à ce moment-là ça revenait beaucoup plus cher, si je peux l'émuler logiciellement ça me conviendrait aussi. ;)

Mon objectif en plus d'un serveur ennuyeux c'est une consommation minimale, actuellement avec 1 modem + 2 NAS Synology + Serveur Debian + Pare-feu pfSense + 1 switch 24p + 1 switch PoE 8p je tourne à 55W en idle, ce que je trouve correct.

Je m'attarderai sur tes retours concernant le 10 Gb/s, j'ai fait câbler en cat6a dans les murs en prévision, donc d'ici 5-7 ans je pense que ça pourrait être intéressant, suivant comment l'offre de vitesses (en Belgique) et les besoins informatiques évoluent en général. ;)

#105656
> J'utilise du coup une Debian classique pour sa stabilité.
Bon choix, mais dans un cadre professionnel 2 défauts: les mises à jour de sécurité pas aussi rapides qu'une distrib "classique" et parfois des défauts dans des drivers obsolètes. Mais c'est un excellent choix dans un cadre personnel.

> Seedbox : sur un disque dédié hors grappe RAID, vu le nombre de lecture/écriture constante il va plus vite s'user que les autres.
Pourquoi l'avoir mis à part alors que justement c'est sans doute celui qui a le plus fort débit ?
Après, l'"usure" d'un disque dur mécanique - c'est pas la même histoire pour les SSD! - j'y crois fort peu tant que le disque est
stable mécaniquement, sous amortisseurs, stable en température et avec une température douce (ventilation permanente proche),
de l'ordre des 35°-40°C. C'est plutôt une histoire de pas de chance ou de pur statistique de nos jours.

> Mise en place de tests S.M.A.R.T. réguliers pour m'assurer de la santé du système, monitoring sur 14j via le combo Telegraf, InfluxDB et Grafana.
> J'utilise BorgBackup pour sauvegarder les données de mes conteneurs et mes fichiers de config dans /etc, /home et /root sur mon NAS Synology DS918+.
Irréprochable! Même en tant que pro on ne pousse pas jusque là, on examine chaque projet pour déterminer les coûts en cas de pertes, et
au cas par cas on met en place des systèmes de sauvegarde plus ou moins poussés. Habituellement, parce que les coûts homme sont toujours
les + élevés, on se contente de tout doubler dans un autre endroit, et de faire des équivalents rsync, histoire que si le premier NAS devient inopérant
pour reconstruction, le second prenne le relais immédiatement.

> Le BTRFS n'a pas les mêmes exigences matérielles que ZFS (1 Go de mémoire par To de stockage si je me souviens bien).
Je ne suis pas pessimiste en ce qui concerne le ration mémoire/stockage de ZFS dans la mesure où je dispose d'une
antémémoire SSD qui débiterait près de 8 GB/s en lecture. En écriture, cela ne sera peut-être pas la même chanson...

> Ce qui m'intéresse dans ton retour c'est la question du réglage du voltage et l'annulation du mode turbo, même en plein transcodage j'ai l'impression qu'il n'est pas employé.
Si tu utilises un Intel iGPU, c'est certain et même plus : il FAUT limiter le CPU en puissance pour en laisser au iGPU! C'est lui qui fait tout le boulot et il est souvent castré en
puissance par le CPU pour des broutilles! Tout les turbo & autres doivent être désactivés dans le BIOS car ils ne concernent que le CPU, et c'est souvent encore insuffisant.

J'ai eu en mains pour de la veille technologique les premiers processeurs Intel équipés de iGPU, et il y a clairement concurrence de demande de puissance entre le iGPU et le CPU,
alors que le processeur est limité en watts. Et c'est très souvent le GPU qui trinque! Il y avait à l'époque des logiciels développés par Intel qui permettaient de changer les priorités
d'attribution de la puissance en temps réel entre le iGPU et CPU, mais il me semble que ce n'était qu'en Windows. Une piste à creuser.

Tu peux essayer des packages de limitation de fréquence processeur, mais la plupart sont mal faits: ils limitent la fréquence par une valeur donnée en dur, alors qu'il
faudrait adapter la fréquence à une puissance totale consommée, voir à une température. Le concept de PDT-down (AMD l'a aussi) qui limite la conso totale moyenne à
une valeur inférieure au PDT est à oublier avec un couple iGPU-CPU: cela castre encore plus l'iGPU.

Sur un i9-10900k, j'ai "réussi" avec un double test de burn CPU et GPU à monter à près de 300 watts de consommation pour un PDT "moyen" annoncé à 125 watts,
et compris pourquoi certains de nos clusters avaient tendance à dépasser leur climatisation :evil:

Après, il existe encore l'"underclocking/undervolting", mais je déconseille avec un Intel (tout du moins jusqu'en 2019), car ils supportent mal ce jeu; ils deviennent assez instables.

> Mon objectif en plus d'un serveur ennuyeux c'est une consommation minimale, actuellement avec 1 modem + 2 NAS Synology + Serveur Debian + Pare-feu pfSense + 1 switch 24p + 1 switch PoE 8p je tourne à 55W en idle, ce que je trouve correct.
Oui... et non. C'est bien pour ce matériel, mais au final beaucoup pour du 24/24 & particulier. J'avais essayé une prise 220V asservie par USB filaire (Wifi, Zigbee, BlueTooth = pas bien)
il y a quelques temps pour démarrer mon matos à distance à partir de mon PC-modem d'entrée de réseau, mais c'était trop lent au démarrage (2 - 3 minutes). J'ai pas vraiment
de solution.

Après, la vraie question est: pourquoi transcoder ? J'en ai de moins en moins recours. Mais c'est vrai qu'entre la tv 180 cm x265 HDR10 du salon et la 80 cm x264 de la chambre, c'est très ennuyeux.
Avatar de l’utilisateur
par Shad
#105657
ALM54 a écrit : 20 juil. 2021 14:20 > Seedbox : sur un disque dédié hors grappe RAID, vu le nombre de lecture/écriture constante il va plus vite s'user que les autres.
Pourquoi l'avoir mis à part alors que justement c'est sans doute celui qui a le plus fort débit ?
Après, l'"usure" d'un disque dur mécanique - c'est pas la même histoire pour les SSD! - j'y crois fort peu tant que le disque est
stable mécaniquement, sous amortisseurs, stable en température et avec une température douce (ventilation permanente proche),
de l'ordre des 35°-40°C. C'est plutôt une histoire de pas de chance ou de pur statistique de nos jours.

Mes disques sont en quasi permanence à 27-28°C, à la cave dans un rack maison fait à partir des LACK d'IKEA (je dois encore prévoir l'étanchéité à la poussière et l'extraction d'air chaud). Le débit est minuscule, ma connexion belge est famélique (100/20) si on tient compte des standards français. Je suivrais bien attentivement ton architecture si j'avais une connexion 10 Gbe symétrique à la Suisse. :D

ALM54 a écrit : 20 juil. 2021 14:20 Habituellement, parce que les coûts homme sont toujours les + élevés, on se contente de tout doubler dans un autre endroit, et de faire des équivalents rsync, histoire que si le premier NAS devient inopérant pour reconstruction, le second prenne le relais immédiatement.

Bon à savoir, je ne me suis pas encore frotté à rsync, j'ai un solide plan de sauvegarde qui implique toutefois qu'en cas d'incapacité complète du serveur je doive disposer d'une autre machine et restaurer les fichiers. Ca pourrait être intéressant d'avoir une machine de secours, un mini-PC par exemple, et mettre ça en place.

ALM54 a écrit : 20 juil. 2021 14:20 Si tu utilises un Intel iGPU, c'est certain et même plus : il FAUT limiter le CPU en puissance pour en laisser au iGPU! C'est lui qui fait tout le boulot et il est souvent castré en
puissance par le CPU pour des broutilles! Tout les turbo & autres doivent être désactivés dans le BIOS car ils ne concernent que le CPU, et c'est souvent encore insuffisant.

Ok c'est noté !

ALM54 a écrit : 20 juil. 2021 14:20 J'ai eu en mains pour de la veille technologique les premiers processeurs Intel équipés de iGPU, et il y a clairement concurrence de demande de puissance entre le iGPU et le CPU,
alors que le processeur est limité en watts. Et c'est très souvent le GPU qui trinque! Il y avait à l'époque des logiciels développés par Intel qui permettaient de changer les priorités
d'attribution de la puissance en temps réel entre le iGPU et CPU, mais il me semble que ce n'était qu'en Windows. Une piste à creuser.

Tu peux essayer des packages de limitation de fréquence processeur, mais la plupart sont mal faits: ils limitent la fréquence par une valeur donnée en dur, alors qu'il
faudrait adapter la fréquence à une puissance totale consommée, voir à une température. Le concept de PDT-down (AMD l'a aussi) qui limite la conso totale moyenne à
une valeur inférieure au PDT est à oublier avec un couple iGPU-CPU: cela castre encore plus l'iGPU.

Sur un i9-10900k, j'ai "réussi" avec un double test de burn CPU et GPU à monter à près de 300 watts de consommation pour un PDT "moyen" annoncé à 125 watts,
et compris pourquoi certains de nos clusters avaient tendance à dépasser leur climatisation :evil:

Après, il existe encore l'"underclocking/undervolting", mais je déconseille avec un Intel (tout du moins jusqu'en 2019), car ils supportent mal ce jeu; ils deviennent assez instables.

Je pense que dans un premier temps, je vais me contenter de désactiver le mode turbo. L'abaissement de la fréquence semble bien plus complexe à réaliser.

ALM54 a écrit : 20 juil. 2021 14:20 Mon objectif en plus d'un serveur ennuyeux c'est une consommation minimale, actuellement avec 1 modem + 2 NAS Synology + Serveur Debian + Pare-feu pfSense + 1 switch 24p + 1 switch PoE 8p je tourne à 55W en idle, ce que je trouve correct.
Oui... et non. C'est bien pour ce matériel, mais au final beaucoup pour du 24/24 & particulier. J'avais essayé une prise 220V asservie par USB filaire (Wifi, Zigbee, BlueTooth = pas bien)
il y a quelques temps pour démarrer mon matos à distance à partir de mon PC-modem d'entrée de réseau, mais c'était trop lent au démarrage (2 - 3 minutes). J'ai pas vraiment
de solution.

Le problème étant que mon NAS de sauvegarde sert à mes sauvegardes, ainsi que celles de deux amis dont je m'occupe de la gestion de leur NAS.
Donc il deviendrait compliquer de planifier ces démarrages et arrêts pour un gain très minime selon moi (c'est un DS118 sur lequel rien ne tourne, ça doit consommer que dalle je pense). Ce qui consomme le plus c'est le serveur Debian. Mais je ne vois pas trop comment réduire sa consommation sans me passer de servicess dont j'use quotidiennement.

ALM54 a écrit : 20 juil. 2021 14:20Après, la vraie question est: pourquoi transcoder ? J'en ai de moins en moins recours. Mais c'est vrai qu'entre la tv 180 cm x265 HDR10 du salon et la 80 cm x264 de la chambre, c'est très ennuyeux.

Je suis dans la même configuration, avec en plus une Shield Pro sur la TV de la chambre, donc pas de transcodage. En revanche le bitrate de certains de mes fichiers excède mon débit montant maximal, donc quand ma famille consulte ma médiathèque il y a nécessairement transcodage. Peut-être que le CPU gère ça très bien tout seul, et qu'un processeur AMD aurait pu faire l'affaire, mais j'ai acheté la plupart de mes pièces soit de deuxième main, soit en (grosse) promotion, donc le iGPU me convient parfaitement. :P

Wireguard n'est effectivement pas compatible avec […]

surveillance center plugin

Bon j'ai trouvé d'ou vient le problè[…]

Bonjour, J'essaie actuellement d'accéder &[…]

HBS3 file backups

je confirme que tout est OK depuis que j'ai format[…]

Site hébergé sur un serveur IKOULA

Ikoula