Lire le Log du Miner — Diagnostic

Le SoloFury Miner Log Report est un instantané textuel complet de votre activité de solo mining, généré à la demande depuis la page /miner/. Il inclut le hashrate en temps réel, le diagnostic de santé par worker, la qualité des shares, les suggestions d’optimisation de la difficulté, les statistiques 24 heures avec graphique ASCII, les blocs trouvés, et le contexte pool/réseau — le tout dans un fichier .log auto-contenu que vous pouvez sauvegarder, partager ou alimenter des scripts.

Contrairement à une capture d’écran du tableau de bord, le log est du texte structuré que vous pouvez sauvegarder pour des archives historiques, partager avec le support, parser avec des scripts, ou joindre comme preuve en cas de problèmes de pool.

Comment télécharger votre log

1. Ouvrez solofury.com/miner/ avec votre wallet dans l’URL : ?addr=VOTRE_WALLET&coin=COIN
2. Attendez que le tableau de bord se charge complètement (3-5 secondes — le rapport utilise des données API en direct)
3. Cliquez sur le bouton .LOG en haut à droite de la carte d’identité
4. Votre navigateur télécharge un fichier nommé solofury-COIN-WALLET-DATE.log

1. Executive Summary

Vue d’ensemble en un coup d’œil : statut, workers, hashrate actuel vs moyenne 24h, blocs lifetime, total miné, et problèmes principaux. Lisez ceci en premier — il vous dit s’il y a quelque chose à investiguer.

Valeurs de statut

• ✓ ALL GOOD — tous les workers sont sains, aucune dégradation supérieure à 25 %
• ⚠ ISSUES DETECTED — un ou plusieurs workers ont des avertissements (chutes 25-50 %, shares tardives 3-10 min)
• ⚠ CRITICAL — un ou plusieurs workers sont hors ligne (>10 min) ou sévèrement dégradés (>50 %)

La liste “Top issues to investigate” liste les éléments les plus urgents. Si votre rapport est ALL GOOD, vous pouvez arrêter de lire et revenir demain.

2. Overview

Stats agrégées au niveau du wallet :

• Hashrate snapshot — moyennes mobiles sur différentes fenêtres temporelles. La 1m est la plus volatile ; la 7d est le benchmark le plus stable.
• Workers / ASIC online — nombre de mineurs actifs.
• Shares (lifetime) — totaux depuis que votre wallet s’est connecté pour la première fois. Décomposition acceptées/rejetées/invalides/périmées/dupliquées.
• Efficiency — % de shares soumises acceptées. Cible : 99,9 %+.
• Luck (round) — votre chance pour le round de bloc actuel. Au-dessus de 100 % signifie que vous avez déjà soumis plus de shares que statistiquement attendu pour trouver un bloc.
• Best share / Best ever — votre share de difficulté la plus élevée. Plus proche de la cible réseau = plus proche de trouver un bloc.

3. Worker Health Analysis

C’est la section la plus importante pour le dépannage. L’analyseur compare le hashrate actuel de chaque worker à ses moyennes mobiles sur 1h et 24h, et vérifie quand il a soumis sa dernière share.

Niveaux de sévérité

Que faire — cas typiques

• Hors ligne > 10min — vérifiez l’alimentation, le câble réseau, l’URL stratum toujours accessible
• Hashrate -50% ou plus — probablement throttling thermique ou défaillance de hashboard ; vérifiez d’abord le refroidissement
• Hashrate -25 à -50 % — dégradation légère, surveillez 30min avant d’agir
• Shares tardives mais hashrate normal — problème réseau/stratum ; vérifiez le relay (Frankfurt/Atlanta/Singapore) auquel vous êtes connecté

Le log inclut des actions suggérées pour chaque worker problématique, adaptées au problème spécifique.

4. All Workers (tableau)

Vue tabulaire complète de tous les workers, quel que soit leur statut. Utile pour comparer les performances côte à côte.

Colonnes expliquées

• HASHRATE / 1H AVG / 24H AVG / 7D AVG — moyennes sur différentes fenêtres temporelles. La 7d montre votre capacité “réelle”.
• UPTIME — temps total de connexion du worker (depuis le premier share).
• BEST DIFF — la share de difficulté la plus élevée jamais soumise par ce worker. Plus élevé = plus proche d’un bloc.
• LAST SHARE — temps depuis la dernière share soumise. Doit être <1min en fonctionnement normal.
• STATUS — santé actuelle (voir section 3).

5. Difficulty Optimization

Le pool utilise vardiff (difficulté variable) : il ajuste automatiquement la difficulté des shares pour que chaque worker soumette environ 1 share toutes les 10 secondes. Cette section indique si la difficulté actuelle est optimale.

Formule

optimal_diff = hashrate × 10 / 2³²

Actions

• ↑ raise +X% — la diff actuelle est trop basse ; vous inondez le pool de shares de faible valeur. Le pool s’ajustera automatiquement (ou vous pouvez définir password=d=NOMBRE manuellement).
• ↓ lower -X% — la diff actuelle est trop élevée ; vous soumettez trop peu de shares pour un suivi fluide. Particulièrement pertinent pour les Bitaxe à faible hashrate.
• ≈ already optimal — aucune action nécessaire.

6. Share Quality Analysis

Décomposition des rejets de shares par type :

• Reject — soumis mais invalide (cible incorrecte, mauvais travail). Pointe souvent vers une corruption réseau ou des problèmes de firmware.
• Invalid — share malformé. Doit être quasi-zéro.
• Stale — share pour un bloc obsolète (votre mineur était encore sur le bloc précédent quand un nouveau est arrivé). Un peu de staleness est normal ; >1 % suggère une latence vers le pool.
• Duplicate — même share soumis deux fois. Généralement un glitch réseau.

Badges de qualité

• ⭐ Excellent — taux de mauvaises shares < 0,1 % (une share sur mille ou moins fréquent)
• ✓ Good — taux de mauvaises shares < 1 %
• ⚠ Below normal — taux de mauvaises shares > 1 % ; investigez le réseau ou le firmware

7. Statistics (last 24h)

Métriques agrégées depuis l’endpoint du graphique 24h (échantillons toutes les 5 minutes) :

• Hashrate avg / max / min — plage quotidienne. Un grand écart entre min et max suggère une instabilité.
• Peak vs avg — combien vos pics dépassent la moyenne. <20 % est fluide ; >50 % suggère un comportement on/off.
• Effective uptime — % d’échantillons avec un hashrate supérieur à 10 % de la moyenne. 100 % signifie un fonctionnement continu.
• Shares 24h — comptages quotidiens de shares. Comparez à votre baseline habituelle pour repérer des régressions.

8. Wallet-Level Outages

Liste les pannes totales du wallet dans les dernières 24h, où le hashrate total du wallet est tombé en dessous de 15 % de sa moyenne. Cela détecte des cas comme :

• Panne de courant dans votre installation de minage
• Défaillance réseau de votre côté
• Panne côté pool (rare, mais possible)

Les problèmes par worker (quand seulement un mineur sur plusieurs tombe en panne) ne sont pas montrés ici — ils sont dans la section 3.

9. Hashrate Timeline (24h)

Vue en deux parties de l’évolution du hashrate sur 24 heures :

• Graphique ASCII — un aperçu visuel rapide de la courbe de hashrate. Les étiquettes de l’axe Y montrent les valeurs absolues ; l’axe X s’étend de il y a 24h à maintenant.
• Instantanés horaires — une ligne par heure, montrant votre hashrate et la difficulté réseau à ce moment.

Utilisez cela pour repérer des schémas : cycles quotidiens/hebdomadaires, déclins lents, chutes brutales.

10. Blocks Found by this Wallet

Liste réelle des blocs trouvés par votre wallet sur ce pool. Chaque entrée montre :

• HEIGHT — hauteur du bloc blockchain (vérifiable sur n’importe quel explorateur de blocs)
• DATE — timestamp UTC du bloc
• WORKER — quel worker spécifique a soumis la share gagnante

Ces données sont récupérées depuis l’API blocs du pool filtrée par votre adresse wallet.

11. Network Context

Le contexte blockchain plus large pour votre coin :

• Network hashrate / difficulty — totaux actuels sur toute la blockchain.
• Your share of net — fraction du hashrate total du réseau que vous contribuez.
• Statistical TTF — Time To Find le prochain bloc, statistiquement. Calculé comme 1 / (votre_HR / network_HR × blocs_par_jour). La chance réelle varie énormément : vous pourriez trouver un bloc en 1 heure ou prendre 10× le TTF statistique.

12. Pool Context

Stats à l’échelle du pool SoloFury : hashrate, mineurs, workers, comptages inactifs/déconnectés, frais, chance, uptime. Utilisez cela pour vérifier que le pool est sain quand vous dépannez votre propre configuration. Si les stats du pool semblent normales mais votre mineur montre des problèmes, le problème est de votre côté.

Questions fréquemment posées

À quelle fréquence dois-je télécharger un log ?

Pour une surveillance active : une fois par jour ou chaque fois que vous remarquez un comportement anormal. Pour les archives historiques : hebdomadairement ou mensuellement. Le log est petit (~10-50 Ko) donc en stocker beaucoup est bien. Le Report ID unique dans l’en-tête vous permet de référencer des rapports spécifiques dans les emails de support.

Puis-je scripter la génération du .log ?

Pas directement (le bouton déclenche du JS côté client), mais vous pouvez récupérer les mêmes données API sous-jacentes : https://solofury.com/api/client/VOTRE_WALLET, /api/pool, /api/client/VOTRE_WALLET/chart?range=24h. Tous retournent du JSON. Vous pouvez construire votre propre rapport depuis ces endpoints dans n’importe quel langage.

Le log dit que mon worker a une chute de hashrate mais le tableau de bord semble normal — pourquoi ?

La valeur “now” peut brièvement monter en flèche pendant que les moyennes 1h/24h restent plus basses (ce sont des fenêtres glissantes). Si “now” > “1h avg” mais le log avertit d’une chute vs “24h avg”, cela signifie que votre worker a fonctionné sous sa capacité pendant la majeure partie de la journée mais vient de remonter. Le log compare contre la référence à plus long terme pour détecter les problèmes soutenus.

Le “Statistical TTF” dit 30 jours — est-ce que ça signifie que je trouverai un bloc dans 30 jours ?

Non. Le TTF statistique est le temps moyen attendu. En raison de la distribution exponentielle de la découverte de blocs, vous avez une probabilité de ~63 % de trouver un bloc dans 1 TTF (30 jours ici), ~86 % dans 2 TTFs (60 jours), et ~95 % dans 3 TTFs (90 jours). Certaines semaines vous trouverez deux blocs, d’autres aucun. C’est la nature du solo mining.

Quelle est la différence entre les shares “Rejected” et “Invalid” ?

Rejected : la share était valide en format mais ne répondait pas à la difficulté cible (souvent dû à un travail périmé ou une diff basse). Invalid : la share était malformée (mauvais format, mauvais nonce). Invalid est presque toujours un bug logiciel/firmware. Rejected peut être normal en petites quantités (latence réseau).

Je vois “LATE share” mais mon worker mine — qu’est-ce qui ne va pas ?

“LATE share” signifie >3 min depuis la dernière share. Causes possibles : coupure réseau vers le stratum, difficulté très élevée (faible fréquence de shares attendue), ou le mineur est hors ligne mais le pool n’a pas encore complètement détecté. Vérifiez croisé avec le hashrate du tableau de bord. Si le hashrate s’affiche encore, c’est généralement un problème de connectivité transitoire.

Où puis-je obtenir plus d’aide ?

Envoyez un email à [email protected] avec le fichier .log joint. Incluez le Report ID de l’en-tête — il nous aide à corréler avec nos logs côté serveur. L’équipe du pool vise à répondre dans les 24h.