Stale Rate est la proportion d’événements ou de travail pondéré classés stale dans un ensemble précisément délimité. Cette entrée concerne surtout les shares de pools arrivées ou traitées dans un contexte de tâche de minage périmé.
Avec SetNewPrevHash, Stratum V2 impose de passer au nouveau hash précédent ; seule la job_id référencée reste valide parmi les tâches préparées. Trouver un hash sous l’ancienne cible ne garantit donc pas son utilisation pour le travail actuel. Le diagnostic demande le contexte et les changements de tâche, pas seulement l’heure d’envoi. [Stratum V2 — Mining Protocol]
Exemple : sur 100 soumissions de difficulté égale, 98 sont acceptées, 1 rejetée comme stale et 1 pour une autre raison. Les stale rejetées représentent 1%, mais le rejet total 2%. Cela explique deux numérateurs, pas des seuils opérationnels acceptables. F2Pool définit rejection rate sur toutes les shares soumises. [F2Pool — Rejection and Staled rates]
Braiins convertit une share de difficulté d en d unités de travail de base. Avec une share stale de difficulté 1 et une acceptée de difficulté 9, l’exemple donne 50% par nombre, mais 10% par poids. Les numérateurs et dénominateurs comparés doivent employer la même unité et convention de difficulté. [Braiins — Share difficulty accounting]
F2Pool distingue dans sa documentation les shares “Staled” rémunérées des stale rejetées sans rémunération. Cette politique ne s’applique pas automatiquement à tous les pools. Avant de convertir le pourcentage en recettes perdues, vérifie catégorie, règles d’acceptation et décompte réel ; le nom de l’indicateur ne suffit pas. [F2Pool — Rejection and Staled rates]
Stratum V2 autorise les SubmitShares.Success groupés. new_submits_accepted_count indique les nouvelles soumissions reconnues, new_shares_sum la somme de leurs difficultés. Compter les réponses serveur ne revient donc pas à compter les shares acceptées. SubmitShares.Error porte sequence_number et error_code ; sans distinguer les motifs, toute erreur ne peut être dite stale. [Stratum V2 — Mining Protocol]
BIP152 traite Compact Block Relay entre nœuds P2P, pas la comptabilité des shares du pool. Réduire les données transférées peut affecter la latence des blocs, mais ne fournit pas seul le Stale Rate du mineur. La proportion de blocs concurrents du réseau ne remplace pas celle des soumissions tardives d’un worker précis. [BIP152 — Compact Block Relay]
Le suivi Braiins distingue shares_5m, shares_60m et shares_24h. Utilise la même fenêtre temporelle et le même périmètre de workers au numérateur et au dénominateur. Zéro soumission observée ne mesure pas une perte de 0% : le rapport est indéfini. Les réponses manquantes ou lacunes de suivi ne sont pas automatiquement stale. [Braiins — Worker monitoring windows]
F2Pool relie stale aux conditions réseau, mais cite des erreurs de firmware et le surcadençage pour d’autres rejets. Braiins distingue le test d’accessibilité du serveur de la performance réelle. Examine journaux de tâches, motifs de rejet et connexions sur la même période ; un ping ou un pourcentage global plus bas ne prouve pas la suppression de la cause. [F2Pool — Rejection and Staled rates] [Braiins — Connection diagnostics]
Pour une vision complète, lisez aussi Mining Share, Share Difficulty, Mining Latency, Pool Fee. Cette entrée est également citée par Stale Block, Mining Latency.