Qu'est-ce qu'un fichier DAG dans Ethereum Mining ? Comment cela affecte-t-il les anciens GPU ?

Comprendre le fichier DAG dans Ethereum Mining

1. Le fichier DAG (Directed Acyclic Graph) est un grand ensemble de données généré par l'algorithme Ethash, qu'Ethereum a utilisé avant sa transition vers Proof of Stake.

2. Ce fichier est requis pour chaque opération de minage et doit être entièrement chargé dans la VRAM du GPU avant que le hachage puisse commencer.

3. Sa taille augmente avec le temps à chaque époque – environ tous les 30 000 blocs – augmentant d'environ 8 Mo par époque.

4. À l'époque 400, le fichier DAG dépassait 4 Go ; à l'époque 450, il dépassait 4,5 Go, exerçant une pression importante sur le matériel limité en mémoire.

5. Les mineurs ne peuvent pas contourner ou compresser le DAG ; il doit résider entièrement dans la mémoire GPU sous la forme d'un seul bloc contigu pendant l'exécution du noyau.

Impact sur les besoins en mémoire GPU

1. Les GPU avec moins de 4 Go de VRAM sont devenus non viables pour le minage d’Ethereum une fois que le DAG a dépassé ce seuil à la mi-2020.

2. Des cartes comme la GTX 970 – qui annonçaient 4 Go mais ne fournissaient que 3,5 Go de mémoire entièrement adressable – ont subi une grave dégradation des performances en raison de la fragmentation de la mémoire et des défauts de page.

3. Même les GPU d'exactement 4 Go, comme le RX 480, connaissaient une instabilité lorsque la taille du DAG approchait de 4,1 Go, déclenchant des réallocations répétées de mémoire et des délais d'attente des pilotes.

4. La bande passante mémoire a également joué un rôle essentiel : les anciens GPU dotés de mémoire GDDR5 fonctionnant avec une bande passante effective inférieure avaient du mal à alimenter les unités de calcul assez rapidement, réduisant ainsi les taux de hachage effectifs malgré la capacité théorique.

5. Certains mineurs ont tenté d'utiliser la RAM du système via des transferts PCIe, mais cela a introduit des pénalités de latence supérieures à 40 %, rendant de telles configurations pratiquement inutiles.

Limitations des pilotes et du micrologiciel sur le matériel hérité

1. Les GPU plus anciens reposaient souvent sur des piles de pilotes héritées qui ne recevaient plus de mises à jour des fournisseurs, ce qui entraînait une mauvaise prise en charge des allocations de mémoire importantes requises par les nouvelles époques DAG.

2. Les cartes d'architecture NVIDIA Kepler (par exemple, GTX 680) n'ont pas réussi à initialiser le DAG au-delà de l'époque 350 en raison de l'épuisement du tas de pilotes internes, même lorsque la VRAM semblait suffisante.

3. Les puces AMD GCN 1.0 (par exemple, HD 7970) rencontraient des erreurs de mappage de mémoire au niveau du micrologiciel lorsque la taille du DAG dépassait 3,2 Go, provoquant des plantages du noyau OpenCL sans codes d'erreur clairs.

4. Les restrictions de synchronisation de la mémoire au niveau du BIOS sur les cartes de marque OEM empêchaient un fonctionnement stable dans des modèles d'accès DAG à large bande passante soutenus, conduisant à des redémarrages intermittents.

5. Certains chipsets de cartes mères limitaient la négociation des voies PCIe pour les anciens GPU, réduisant ainsi le débit mémoire effectif et exacerbant les échecs de chargement du DAG.

Solutions de contournement et leurs inconvénients

1. Les outils d'élagage DAG prétendaient réduire l'empreinte mémoire, mais violaient la conformité aux spécifications Ethash, entraînant le rejet de partages sur tous les principaux pools.

2. Les plates-formes multi-GPU utilisant des cartes hétérogènes étaient confrontées à des problèmes de synchronisation : un seul GPU ne parvenant pas à charger le DAG bloquerait l'ensemble du processus d'extraction.

3. L'overclocking des timings de la VRAM a parfois prolongé la convivialité de quelques époques, mais a augmenté les taux d'erreur binaire, provoquant une corruption silencieuse des partages indétectable sans validation externe.

4. L'utilisation de Linux avec des paramètres de noyau personnalisés permettait un contrôle plus approfondi de la gestion de la mémoire, mais de nombreux GPU existants ne disposaient pas d'une prise en charge appropriée des pilotes open source pour les charges de travail Ethash.

5. Le flashage des fichiers VBIOS modifiés comportait un risque matériel permanent ; des tables de synchronisation incorrectes ont entraîné des blocages du GPU nécessitant une réinitialisation physique ou une récupération du BIOS.

Foire aux questions

Q : Puis-je exploiter Ethereum avec une GTX 1050 Ti une fois que la taille du DAG a atteint 4,2 Go ? La GTX 1050 Ti ne dispose que de 4 Go de mémoire GDDR5 et ne dispose pas de la marge de bande passante nécessaire pour maintenir un fonctionnement stable au-delà de l'époque 380. Elle échoue systématiquement à la génération de DAG ou produit des partages non valides.

Q : Pourquoi certains modèles AMD RX 570 avec 4 Go sont-ils toujours exploités alors que d'autres échouent ? La variation du regroupement des circuits intégrés de mémoire et de la disposition des circuits imprimés a affecté l'intégrité du signal lors d'un accès DAG haute fréquence. Les unités équipées de puces mémoire Micron avaient tendance à surpasser celles équipées d'Hynix, en particulier au-delà de l'époque 410.

Q : La taille du DAG affecte-t-elle également le minage du CPU ? Le minage de CPU n'a jamais été viable pour Ethereum en raison de la conception exigeante en mémoire d'Ethash. Le modèle d'accès séquentiel à la mémoire du DAG pénalise fortement les hiérarchies de cache du processeur, ce qui fait que même les systèmes Xeon haut de gamme fournissent moins de 1 MH/s.

Q : Existe-t-il un outil officiel de la Fondation Ethereum pour vérifier la compatibilité DAG ? Aucun utilitaire officiel n'existait. Les mineurs se sont appuyés sur des calculateurs d'époque gérés par la communauté et des scripts de référence GPU qui simulaient le comportement de chargement du DAG sous des contraintes de mémoire réelles.