Comment augmenter le hashrate sur les mineurs Linux ? (Optimisation du noyau)

Comprendre le hashrate et ses dépendances

1. Le hashrate mesure la puissance de calcul qu'une plate-forme minière apporte à un réseau blockchain, exprimée en hachages par seconde (H/s).

2. Cela dépend des capacités matérielles (GPU, ASIC ou CPU), mais également de l'efficacité avec laquelle le noyau Linux planifie les tâches et gère les ressources.
3. Les goulots d'étranglement au niveau du noyau incluent la latence de gestion des interruptions, les politiques de mise à l'échelle de la fréquence du processeur et les stratégies d'allocation de mémoire.
4. Des configurations de noyau sous-optimales peuvent limiter l'accès aux périphériques, retarder la soumission des commandes GPU ou provoquer des changements de contexte inutiles lors de cycles de hachage intensifs.
5. Les charges de travail minières sont hautement déterministes et répétitives, ce qui les rend sensibles à la gigue de planification de l’ordre de la microseconde et aux temps d’attente d’E/S.

Réglage des paramètres du noyau pour la stabilité minière

1. La désactivation des pages transparentes énormes (THP) évite les retards imprévisibles de compactage de la mémoire : echo never > /sys/kernel/mm/transparent_hugepage/enabled .

2. Le réglage du gouverneur du processeur en mode performance verrouille les fréquences au maximum : cpupower Frequency-set -g performance .
3. L'ajustement de vm.swappiness à 1 minimise l'utilisation du swap sous la pression de la mémoire, préservant ainsi la bande passante RAM pour les tampons d'exploration de données.
4. L'augmentation de net.core.somaxconn et net.ipv4.tcp_max_syn_backlog permet de maintenir des connexions de strate stables lors des soumissions de tâches à haute fréquence.
5. La désactivation du chien de garde NMI avec echo 0 > /proc/sys/kernel/nmi_watchdog élimine les interruptions périodiques du noyau qui interfèrent avec les boucles de hachage critiques en termes de timing.

Planification en temps réel et priorisation des processus

1. L'attribution de processus d'exploration de données à une classe de planification en temps réel (SCHED_FIFO) réduit la latence de préemption : chrt -f -p 99 $(pidof lolMiner) .

2. L'isolation des cœurs de processeur à l'aide du paramètre de démarrage du noyau isolcpus=2,3,4,5 empêche les démons d'arrière-plan d'interférer avec les threads d'exploration de données.
3. La liaison des processus de mineur GPU à des nœuds NUMA spécifiques garantit une latence d'accès à la mémoire cohérente lors de l'alimentation des noyaux vers la VRAM.
4. L'utilisation de cgroups v2 pour allouer une bande passante CPU dédiée et des limites de mémoire empêche les services système d'affamer les charges de travail d'exploration de données.
5. La désactivation de l'irqbalance et l'affinage manuel des IRQ liées au GPU aux cœurs isolés évitent les tempêtes d'interruptions lors des lancements de noyau à haute intensité.

Considérations sur le pilote GPU et le module de noyau

1. Le chargement des pilotes NVIDIA avec NVreg_RegistryDwords='PerfLevelSrc=0x2222' force les états d'horloge du GPU fixes, éliminant ainsi les artefacts de limitation dynamique.

2. Pour les GPU AMD, le réglage amdgpu.ppfeaturemask=0xffffffff permet un contrôle complet de la gestion de l'alimentation requis pour des taux de hachage overclockés stables.
3. La compilation de modules de noyau personnalisés avec les correctifs CONFIG_PREEMPT_RT améliore le déterminisme dans la synchronisation du tampon GPU DMA.
4. La mise sur liste noire des modules inutilisés comme Bluetooth, snd_hda_intel ou uas réduit le temps de chargement des modules du noyau et la fragmentation de la mémoire.
5. L'activation de CONFIG_CPU_FREQ_STAT et CONFIG_IRQSOFF_TRACER permet un profilage précis des pics de latence induits par le planificateur affectant le débit de la boucle de hachage.

Foire aux questions

Q : L'optimisation du noyau peut-elle augmenter le hashrate sur les mineurs ASIC ? R : Les mineurs ASIC exécutent généralement un micrologiciel propriétaire et ne s'appuient pas sur la planification du noyau Linux pour la logique de hachage de base ; cependant, le réglage du noyau améliore toujours la stabilité de la communication entre les strates et la précision des rapports thermiques.

Q : La désactivation de THP affecte-t-elle les algorithmes gourmands en mémoire comme Ethash ? R : Oui : Ethash s'appuie fortement sur les modèles d'accès à la mémoire du DAG ; THP peut provoquer des blocages de migration de pages et des latences de lecture incohérentes, réduisant directement le hashrate effectif jusqu'à 3 % sur les grands DAG.

Q : Pourquoi éviter le gouverneur de processeur « à la demande », même s'il évolue sous charge ? R : Le régulateur à la demande introduit une latence variable lors des transitions de fréquence ; le minage nécessite une exécution immédiate et soutenue aux heures de pointe, sans délais d'accélération entre les soumissions de tâches.

Q : Est-il sûr de désactiver kptr_restrict et dmesg_restrict pour les systèmes de minage ? R : Oui : les plates-formes minières fonctionnent dans des environnements contrôlés où les fuites de pointeurs du noyau ne constituent pas un vecteur de menace ; la désactivation de ces restrictions permet aux outils de surveillance de lire les métriques du planificateur interne nécessaires au réglage fin.