Quelle quantité de RAM pour miner Blocknet ?

Choisissez des threads CPU adaptés à la mémoire disponible. Ce guide détaille les allocations de 2 GiB, le réglage automatique de seine v0.2.26 et les vérifications après un échec d’allocation manuelle. Le guide matériel conserve les comparaisons de processeurs et les mesures de hashrate. Les exemples ci-dessous sont des calculs de mémoire, pas des benchmarks.

Combien de RAM faut-il par thread ?

GiB est une unité binaire : 2 GiB représentent 2 147 483 648 octets. La zone est réutilisée entre les hashes ; chaque hash terminé ne consomme pas définitivement 2 GiB supplémentaires. Davantage de threads simultanés demandent davantage de zones. L’explication d’Argon2id décrit ce besoin de mémoire de travail.

Comment calculer un budget de threads ?

Multipliez le nombre de threads CPU par 2 GiB. Le tableau exclut le système et les autres besoins mémoire. Utilisez-le pour calculer les allocations ; choisissez les threads réels selon la mémoire disponible et le débit mesuré.

Quatre threads demandent 8 GiB pour leurs zones : il faut donc plus de 8 GiB disponibles pour couvrir aussi le processus et le système. En réservant volontairement 4 GiB sur une machine de 16 GiB, les 12 GiB restants peuvent contenir six zones. C’est un choix de budget, sans garantie que six threads donnent le meilleur hashrate.

Vérifiez la mémoire disponible avec vos applications habituelles ouvertes : Gestionnaire des tâches Windows, Moniteur d’activité macOS ou outils Linux. Une machine virtuelle ou un conteneur peut disposer de moins de mémoire que l’hôte. Calculez avec cette limite effective ; la RAM annoncée de l’hôte n’est pas automatiquement accessible dans cet environnement.

Comment seine choisit-il les threads automatiquement ?

Pour un premier lancement CPU seul, ne fixez pas les threads. Exécutez cette commande dans le dossier extrait sous Linux ou macOS. Sous Windows, utilisez les mêmes options avec l’exécutable dans PowerShell. Le guide de démarrage explique le téléchargement et la saisie de l’adresse de réception.

./seine --backend cpu

Dans v0.2.26, le dimensionnement et le réglage automatiques réservent par défaut 5% de la RAM totale effective, en plus de tenir compte de la mémoire déjà utilisée. Les ressources CPU bornent aussi le nombre. Pour réduire la plage de recherche, fixez un maximum :

./seine --backend cpu --cpu-autotune-max-threads 4

Quatre est un plafond d’exemple. Le réglage peut choisir moins de threads. Observez le nombre retenu et le hashrate moyen dans le tableau de bord. Le réglage mesure votre configuration réelle ; laissez-le se stabiliser avant de juger une modification sur une brève fluctuation.

Quand fixer le nombre de threads ?

Fixez-le pour respecter un budget précis ou obtenir une configuration reproductible. Cet exemple sélectionne deux threads CPU, soit 4 GiB pour leurs zones, auxquels s’ajoutent les autres besoins :

./seine --backend cpu --threads 2

L’option --threads désactive la sélection automatique ordinaire, sauf activation explicite du réglage. Elle remplace la politique de réserve automatique : gardez votre propre marge. Les contrôles mémoire restent actifs. Un nombre compatible avec la RAM installée peut dépasser la mémoire disponible après le lancement d’autres applications.

Modifiez un réglage à la fois. Notez les threads, la RAM disponible et le hashrate moyen sous des charges comparables. Pour revenir à l’automatique, retirez l’argument fixe et toute valeur enregistrée qui l’impose. La référence v0.2.26 explique l’application des paramètres enregistrés et de la ligne de commande.

Que vérifier après une erreur d’allocation ?

Distinguez la limite mémoire effective, la mémoire actuellement disponible et l’allocation explicite de grandes pages dans le message. Les vérifications diffèrent. Fermez les applications inutiles, réduisez les threads et recommencez avec de la marge pour l’usage normal du bureau.

Pour un conteneur ou une machine virtuelle, contrôlez la mémoire attribuée ainsi que celle de l’hôte. Une limite de 1 GiB ne contient pas une zone de 2 GiB. Agrandir le fichier d’échange ne change pas ce besoin ; prévoyez suffisamment de mémoire physique accessible au processus.

Avec --cpu-page-mode large ou --cpu-page-mode large-1g, vérifiez la disponibilité de la réserve de pages demandée. Ces modes exigent le type de pages choisi. Consultez le guide des huge pages, ou revenez à la sélection automatique pour établir une configuration fonctionnelle. Séparez les changements de pages et de threads.

La mémoire GPU entre-t-elle dans le budget CPU ?

Sur une carte NVIDIA dédiée, les zones GPU résident en VRAM. Les threads CPU utilisent toujours la RAM système. Dimensionnez séparément ces ressources en minage CPU et GPU combiné ; la VRAM libre n’ajoute pas de RAM aux zones CPU. Le guide NVIDIA explique la configuration et les lanes GPU.

Sur Apple Silicon, CPU et GPU partagent la mémoire unifiée. Ne comptez pas deux fois cette capacité en prévoyant d’autres charges. Suivez le guide Mac pour la configuration CPU prise en charge. La capacité indique ce qui tient ; le débit mesuré détermine la configuration la plus adaptée.

Que vérifier avant de laisser tourner le mineur ?

Vérifiez que les threads respectent le budget, que les applications restent réactives et que les shares acceptés arrivent. Une allocation supérieure ne prouve pas à elle seule un meilleur rendement. Gardez la configuration adaptée à votre usage, puis consultez le guide de suivi du pool pour confirmer du travail récent à votre adresse.